Re: Loki SmartPtr study: Policy orthogonality issues

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-07 16:31:29

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> 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

SmartPtr implements very simple models of "Resource holder". It 
1. aquire resource
2. Provide an access to it.
3. release resource

(1) is implementing using constructors and assignment operators 
(maybe method 'reset' also)
(2) is implemented with operator*, operator->, direct resource access 
using free function like GetImpl
(3) is implemented using destructor (and probably method 'release')

That's it. This is fixed interface. And it should stay that way. 
Policies should not be allowed to expand it. Any other access methods 
could be implemented outside of SmartPtr (which I assume will be very 
rare case). For example operator[] for arrays could be implemented 
like this:

template<T,...>
class SmartArray : public SmartPtr<T,ArrayStoragePolicy,... > {
public:
    // forwarding constructors

    // aimed assecc method
    Reference   operator[]( size_t index )
    {
       return GetImpl(*this)[index];
    }
};

Gennadiy.