Re: [boost] Re: Loki SmartPtr study: Policy orthogonality issues

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-07 15:56:52

At 03:14 PM 1/7/2002, Andrei Alexandrescu wrote:

 >> The difficulty with using the framework to mediate the communication 
via
 >> forwarding functions is that communication is limited to exactly those
 >> forwarding functions and now others. And they are still there even when
 >not
 >> needed.  The forwarding function also represent additional complexity.
 >
 >The idea is that the framework is written by the library designer, and
 >policies can be written by both the library designer and the library 
user.
 >In particular, an important goal of Loki::SmartPtr was to make typical
 >user-defined policies (COM/CORBA ownership, custom checkers, etc.) easy 
to
 >implement. Also, SmartPtr can be fairly intricate because it is designed
 >and
 >implemented only once.
 >
 >That's why I find the design in which SmartPtr is an orchestrator of
 >various
 >policies a natural one. It also was one that satisfied its users.
 >
 >What practical problem requires policies to communicate with each other?

By communicate, I assume you mean directly via inheritance rather than 
indirectly via the framework.

The StoragePolicy needs to know if implicit conversion is requested, 
because it needs (in the case of arrays for sure, but that probably means 
there are other cases too) to supply operator[] or not depending on 
that.  Perhaps you could get around that with your current design by making 
ConversionPolicy a policy of StoragePolicy rather than of the framework.

Another example:  Say a StoragePolicy adds an additional access function to 
the public interface.  There is no way I can see for this additional access 
function to call one of the CheckingPolicy functions.

I haven't totally made up my mind about any of this.  I want to be sure I 
understand the pros and cons in detail.  I'm also looking forward to seeing 
the details Dave's policy adaptor approach.

--Beman