Re: [boost] Re: Re: Boostifying Loki::SmartPtr

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

> > Hi Dave (and co), sorry to come to this late - hope you're still reading
> the
> > thread :-)
>
> You bet.  I'm working on smart_ptr when I have time and motivation. ;)
> And I'm learning as I go, so that slows me down a bit as well.

I think we all are (including Andrea, Greg, Peter, Gennadiy etc)!
I think it's good that someone that is not so close to the existing designs
(of the boost:smart_ptr family and of Loki::SmartPtr) is so actively
involved in this effort.

> > Could the decision as to whether we use a linear inheritance hierarchy
> > or MI be deferred to yet another policy? (YAP?).
>
> Heh, heh.  Sure it could.  But I think that would defeat the purpose of
> using MI in the first place.

I'm not so sure it would. It might water it down a little, but whether that
is too much is perhaps a matter of interpretation. I am not going to defend
this suggestion as staunchly as my case with smart_resources, but I think
there is some merit in it.

> I myself am not intimidated by specifying five or six
> policies for a type, since I usually just do it once or twice, and use a
> typedef everywhere else.  In fact, I consider the full type spelled out,
policies
> and all, as an in-code documentation of what I'm doing.

Sure, although template typedefs will be the panacea for all verbose
template definitions when they come along anyway ;-)
Seriously, now that I think of it, perhaps the policy mixer idiom may even
*help* the whole parameterisation problem in the absence of template
typedefs. All the policies, which are, after all, semantically distinct from
the type being paramerised upon (the pointee type), would be grouped in a
policy_mixer type. The downside is that, with this technique, the pointee
type would still need to be passed down to the individual policies, so a
typedef could not be used for the policy_mixer type as a whole - despite
appearances.
A brief (general) example might be:

    smart_ptr<MyType, policies<MyOwnership, MyStorage, etc...> > mySmartPtr;

.... which might seem more verbose at first (indeed, it definitely contains
more characters), but at least the fact that the pointee type is distinct
from the policies is explicit (and the fact that the policy types are just
that is explicitly documented by the code - which is surely more readable).
With template typedefs you could also typedef your policies, for example:

typedef policies<ComOwnership, ComStorage, ComRefCounted, etc...> ComPolicy;

smart_ptr<MyComType, ComPolicy> myComPtr;

... although you would probably still choose to typedef the whole smart_ptr
as, say, com_ptr or somesuch...

> > By inheriting smart_ptr immediately from, say, policy_mixer (for want of
> > a better thought out name), we leave it to policy mixer how to, well,
mix
> > the policies. [...]
>
> I think if you're going to defer the policies to a mixer, you may as well
go
> the full policy chaining route, IMO.  I think the MI approach allows a
> concise statement of the policies chosen (and I think it's an elegant
design, to
> boot).
> Once you throw in a policy mixer, you're abandoning the implementation
> elegance of the MI approach, and have the verbosity of the chained policy
> approach, so why not just go with that?

That is a good point. If my observation about policy list separation is not
enough to sway the argument, then perhaps other trade-offs between MI and
linear hierarchy designs may emerge that will demonstrate that the
flexibility to choose which hierarchy to use is useful. I don't have any
such examples to pull out of the bag - just ruminating....

Perhaps one way of looking at it, though, is the the policy_mixer could be
written fairly generically (ok, either completely generically - maybe
utilising something like Loki's GenLinearHierarchy, which would require a
means of specifying default parameters but if solved could also mean that
the ordering of parameters need not be fixed - or as a generic idiom, with
more specific implementations). If the policy_mixer can thus be treated as a
black box concept then it clutters the design less than an explicit linear
hierarchy solution and we are only one step away from the elegance of the MI
solution (but with the extra flexibility - and the other benefits I have
mentioned previously).

As a disclaimer to the above, much of this has only occurred to me as I was
writing this mail, so I may be talking rubbish. Please excuse the noise if
so. I have a feeling there is something in it, however, so would appreciate
any feedback one way or another (especially since this issue is not limited
to smart_ptr - and increasingly so if policy-based solutions creep into
boost more and more).

Regards,

[)o
IhIL..