"Hurd, Matthew" <hurdm@sig.com> wrote in message news:BA1220310B07EC4A8E321B451E07AF47314473@msgbal501.ds.susq.com...
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]
On Behalf Of David Abrahams
Rob Stewart <stewart@sig.com> 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.