Re: Loki SmartPtr study: Policy orthogonality issues

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-05 16:03:46

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 02:14 PM 1/5/2002, Andrei Alexandrescu wrote:
> 
>  >As much as I hate wasting bandwith with messages such as "I 
agree", I 
> felt
>  >compelled to underline that Peter hit the nail on the head.
>  >
>  >> >  >The other fundamental problem - that some policy 
combinations are
>  >> >  >nonsensical (array_access with intrusive_storage) - has 
three major
>  >> >  >solutions:
>  >> >  >
>  >> >  >1. Do nothing.
>  >> >
>  >> > I don't think that's acceptable.
>  >>
>  >> I'm not so sure. It looks acceptable - if not perfect - to me. 
Novice
>  >users
>  >> are supposed to use "precanned" variants of smart_ptr<> called
>  >scoped_ptr<>,
>  >> shared_array<>, and so on; the general interface is for power 
users, 
> and
>  >> with power comes responsibility.
>  >>
>  >> I don't mind an implementation catching obvious mistakes as a 
QoI 
> issue,
>  >of
>  >> course.
>  >
>  >
>  >It looks acceptable to me, too.
> 
> If doing nothing means a compile time error, I could live with 
> that.  Although it does sound like settling for second best.  
Explicit 
> error messages would be better.
> 
> If doing nothing means silent runtime failures, I have a hard time 
with 
> that.
> 
>  > The idea is that elaborate uses of smart_ptr
>  >will be almost exclusively through typedefs. Those typedefs are 
put in
>  >place by people who know what they're asking for. It's not like 
any
>  >naive user defines smart_ptr instantiations. Then, of course, 
it's nice
>  >to validate the design at compile time, but this shouldn't be 
done at
>  >the expense of orthogonality.
>  >
>  >> The problem with validating a configuration is that the 
validator must
>  >> recognize each and every policy. This is not possible in the 
general
>  >case.
>  >
>  >My words exactly. SmartPtr has *hundreds* of valid, useful 
behaviors. Its
>  >strength comes exactly from the policies being independent and 
orthogonal
>  >onto each other.
> 
> No, a validator does not need to recognize each and every policy.
> 
> Validators are like other generic components.  Their requirements 
include 
> inherited enums like is_array and disallow_array.
> 
> So the validator does something like:
> 
>     BOOST_STATIC_ASSERT( !disallow_array || !is_array )
> 
> Furthermore, if the validator is itself a policy, then a do-nothing 
version 
> can always be supplied.
> 
> For smart pointers there is probably a limited number of 
configuration 
> validity issues, so a policy class would probably be overkill.  The 
> framework class itself can handle it; isn't that already done by 
Loki 
> SmartPtr once or twice?

But few statements above you sad that we should be able to 
provide 'do-nothing version'. I think that the rationale could be 
like this: every decision that could be made by user should be a 
Policy. Now some related policies couls be compined in 'Policy 
adaptors', though , I assume, it will be a rare case. In general we 
should try to design orthogonal independent policies, while 'policy 
adaptors' provide small reuse level and could cause some other 
problems (like need for extensive use of partial specialization to 
extend one specific policy).

Regards,

Gennadiy.

> 
> --Beman