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

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

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?

--Beman