Re: Loki SmartPtr study: Policy orthogonality issues

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-07 12:56:32

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
Of /course/ I am biased, but I find the approach used by
> SmartPtr using five template template parameters to be much more 
daunting.
> 
> -Dave

But iterator_adaptor also has 7 template parameters (template 
template, or regular in noit important IMO). In general it it not 
obvious what is better to have SmartPtr parameterized using N Policy 
parameters or SmartPtr parameterized with 1 Policies adaptor, which 
in turn is constructed from N Policies. FWIW you just adding a level 
of indirection. Policies adaptor does do a good job for Policies 
communication, but it still questionable how valuable it is. IMO with 
good design you would not need a Plicies to communicate. Having 
independent policies is much more clear. Each policy is responasable 
for separate task and should not try to do what other policy is 
doing. StoragePolicy store a pointer, CheckingPalicy validate 
pointer. And it is a framework responsability to use them in proper 
manner.
  Another thing that I wanted to remark is that having SmartPtr to be 
inherited from PlicyAdaptor ( or separate policies like in MC++D ) is 
brealing encapsulation. Policies IMO are implementation details, 
while SmartPtr should define an interface. It does allow us to extent 
an SmartPtr interface, but do we want it? Why not to do the same way 
iterator_adaptor doing and put Policies object inside of SmartPtr?  
could affect a size of it, but iterator_adaptor found a way around.

Regards,

Gennadiy.