Re: [boost] Smart Pointer Feature Model

From: Beman Dawes (beman_at_[hidden])
Date: 2000-07-13 10:12:39

Kevlin Henney wrote:

 > ...
 >
 >>----- Smart Pointer Feature Diagram  ----
 >>
 >>Draft of 12 July 2000
 >>
 >>smart-pointer  ( ownership
 >>                  release
 >>                  T-visability
 >>                  operations                     // dereference, get, 
etc.
 >
 >I think that dereferencing will open up a whole set of possibilities, ie
 >result as raw pointer, some other kind of proxy (eg for locking), etc.

The initial scope was smart pointers people had discussed on boost.  No 
reason that can't be broadened, but we will just confuse ourselves if we 
try to work out too complicated an example the very first time we use this 
modeling technique.

 >>                  size
 >>                  [multi-ptr-aquisition-safe]    // shared-in-ptr
 >>                )
 >>
 >>ownership      ( tightly-held    // scoped_ptr
 >>                | transferable    // auto_ptr
 >>                | shared          // shared_ptr, linked_ptr, etc.
 >>                | weak            // ??? weak_ptr
 >>                | copyable        // copy_ptr
 >
 >Also: 'unowned'.

Hum... Is it still a smart pointer?  Could you explain a bit?

 >Would 'copyable' read better as 'copied'?

Or 'copy'.  'copyable' isn't very good, for sure.

 >
 >>                          )
 >>
 >>release        ( non-array
 >>                | array
 >>                | user-supplied
 >
 >Also: 'none' -- not all SPs have anything to do with ownership.

You're stretching my mind again. Could you explain?  Oh, maybe I see, it is 
related to ownership::unowned.

Now if I understand correctly, we should specify a constraint that 
ownership::unowned implies release::none.  But isn't that the same 
thing?  Maybe it should be specified as [release], that is, optional, with 
a constraint that it can't be omitted unless ownership::unowned.  It's a 
learning process!

 >>                )
 >>
 >>T-visability   ( complete
 >>                | incomplete-OK-if-trivial-dtor
 >>                | incomplete-OK
 >>                )
 >
 >sp: T-visibility?

Picky, picky.  Fixed.

 >
 >>operations     ( with-conversion-to-T-star
 >>                | without-conversion-to-T-star
 >>                )
 >
 >Is this to be extended to include the shopping list of possibilities
 >available for smart pointers or is it just for conversions?

I don't know.  But we shouldn't go from the extreme of very little 
variation to the other extreme of variation just for its own sake.  There 
would need to be a constituency (what C&E calls stakeholders) who claim to 
have a real need for a given feature.

Another point is that features have what C&E calls the open/closed 
attribute, meaning new sub-features expected or unexpected.  Maybe 
operations should be identified as 'open' and then diagrammed like this:

     operations ( basic-ops, optional-ops[ conversion-to-T-star ] )

then if operator-foo comes along, the diagram changes to:

     operations ( basic-ops,
                  optional-ops[ conversion-to-T-star + operation-foo ] )

In other words, there are four possible optional-ops configurations:

    none
    conversion-to-T-star
    operation-foo
    both conversion-to-T-star and operation-foo

Is this a viable approach and in keeping with C&E?

 >
 >...

I've run out of time; there's no lack of interest in your remaining points. 
But let's do continue the discussion.

--Beman