[boost] Re: Re: Policy or Trait?

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-04-01 20:53:57

"Hurd, Matthew" <hurdm_at_[hidden]> wrote in message
news:BA1220310B07EC4A8E321B451E07AF47314473_at_msgbal501.ds.susq.com...
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]
> > On Behalf Of David Abrahams
> > > Rob Stewart <stewart_at_[hidden]> writes:
> >
> > I think your definitions are mostly on target, but I think where you
> > go wrong is that traits/policies has less to do with how a template
> > is defined than how it's used.
>
> Can a method call be part of a trait class?  I don't think traits should
> have anything to do with enacting behaviour (they may describe it).
>
> If it is not clear and I see a method I think of it as policy-like.  A
> collection of types and static constants and I think of it as
> trait-like.

See my other post on the topic.In short - I disagree.

> I think it gets confusing with the overloading of the English word
> policy.  A policy on how to do something could be passed by value as a
> polymorphic object or as a simple Boolean flag for that matter... which
> is not the common intended meaning that MCD brought into common focus.
>
> I'll try to add something...
>
> Traits are used to get information at compile time.  Policies are used
> to modify behaviour.  Traits could be used by a client to modify
> behaviour which makes them feel like a policy class, but they aren't in
> what we normally think of as a policy.
>
> If a trait is used to direct the modification of behaviour, is it a
> policy from the client classes point of view I guess... which points to
> the terminology confusion.
>
> Policies can be chained, multiply inherited from or just be ordinary
> template classes with static methods, maybe such different styles should
> have different names... a chain aspect, a base aspect (MCD-like), a
> static aspect...
>
> You could then say aspects and traits could be used as policies
> perhaps...
>
> A policy is then something that maybe used to modify behaviour.  A trait
> carries information for use such as for behaviour modification.  An
> aspect extends the definition of trait to also encapsulate behaviour.
>
> An aspect and a trait may be used as a policy.
>
> Does that work?
>
> It would be nice if something new like "aspect class" or some such could
> be defined and used commonly to avoid the mess, but I suspect it is too
> late.

As you admit yourself both trait and policy could be used to modify the way
the component is working. Key here is how/where you do that:

If you supply custom something as a template parameter (or runtime parameter
for that matter - in which case you have an example of runtime policy) -
this is policy.
If you use template specialization to customize the component behavior -
it's an example of a trait. Essentially you modify type definition before
supplying it as a parameter to the component. The best place to do it right
after this type definition. If you intent your users to specify different
traits values in different instantiation of the component - you should be
using policy instead:

a.hpp

class A {}

b.hpp

template<>
my_trait<A> { value = value1; }

my_component<A> my_c1;

c.hpp

template<>
my_trait<A> { value = valueC; }

my_component<A> my_c2;

This is an example if incorrect design. If both usages are valid
my_component should've been defined to accept Policy that defines value to
be used.

Gennadiy.