Re: [boost] RFC: Inheritance alternatives for policy-based smart_ptr

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-04-29 20:18:22

[Gennadiy]
> I would like to discuss and hopefully find some consensus on type of
> inheritance to be used by policy-based smart_ptr. Decision could be
affected
> by specific problems with policies orthogonality. But since I do not have
an
> examples of such problems I expect some from boosters. FWIW we have at
least
> 6 design alternatives (they were presented to boost already, I just want
to
> summarize here):

> 3. Intermediate policies mixer: smart_ptr is parameterized and is
inherited
> from one template parameter, which in turn export all other policies.
> We could provide predefined mixers that will 'mix' in Item 1 style or Item
2
> style.

Being my proposal I would argue in favour of this ;-)
But seriously, I outline some further observations on this option in my
response to David B.Held's mail.
I'll try and fill in your blanks here in summary:

> Pros.
>    a. May resolve issue 1.a if chaining mixer is used.
>    b. More flexible then 1 and 2
>    c. Allow to resolve most interpolicy communications issues (I assume).
>    c. Your comment here

d. Could mature into an idiomatic way of mixing policies in general (at
least where MI might currently be used)
e. Forms a syntactic distinction between data types (the pointee) and
behavioural types (the policies) and makes use of policies explicit - in a
way mitigating the verbose parameter list issue.

> Cons.
>    a. Less elegant and more complex design then 1 or 2
I would argue more elegant than the pure linear hierarchy as the mechanics
are encapsulated in the policy_mixer

>    b. Too flexible that may cause policies incompatibilities. I.e. policy
> intended to be used with MI mixer would not work with chaining mixer. That
> may decrease policies reusability.
If this is a problem it is with the MI or linear hierarchy solutions, and
not specific to a policy_mixer. Although it could be argued that if you can
only chose one then why provide the choice - which is perfectly valid,
what's to stop us creating hybrid solutions to get the best of both worlds -
and all independantly of the smart_ptr implementation?
(though I will confess that, without the immediate choice, the case for
policy_mixer is significantly weakened).

>    c. Since many users would expect to reuse policies supplied with the
> framework they will be bound to decision made by policies implementer ( or
> we need to have all policies implemented in all styles).

Not if the policy_mixer could be made generic (or at least non-intrusive). I
don't have a ready made solution to this, but I'm increasingly persuading
myself that I should go away and come up with one. My mental image of how
this could be done does not have a problem with adding the chaining
mechanism externally and automatically, but I may, of course, not find it so
straightforward to implement.

>    d. Your comment here

My concept of a policy mixer relies perhaps even more heavily on template
template parameters than the original Loki::SmartPtr design. I've not had a
chance yet to look at your version, Gennadiy, so I don't know if you still
have that dependancy. If not it could be a barrier to the policy_mixer
option (without it I think policy_mixer would be too verbose for
practicality).

Regards,

[)o
IhIL..