Rob wrote:
From: "David Bergman" <davidb@home.se>
So, for me it is pretty easy, traits *only* describes Model-invariant parts of Concept Features while policies furnish Models of Concepts.
Skipping all the GP stuff: traits DESCRIBE and policies ACT.
I don't agree. I think it has to do with how the classes are used.
So, if they are *used* to DESCRIBE, they are traits, and if they are used to ACT, they are policies. Satisfied? ;-)
A template parameter permits clients to inject different information and behavior, making it a policy class. When the class is well known and is "just used" where needed, it is a traits class.
I agree with your first statement, that injection of information and behavior defines a policy. If the injection is via a template parameter, it is a compile-time policy. Great. I do not agree with the distinction lying in whether it is a type parameter or not, which your second statement implies. A trait should *not* be used to add behavior, but just to, in the end, specialize behavior - often via template specialization or function overloading on a related type or value provided by the trait, in its role as a meta function. The specialization of behavior is a result of the structural impact of the trait. So, even though the end result is always behavioral (after all, we are dealing with Turing machines ;-)), the trait itself should *not* be behavioral. See the last paragraph of this e-mail for a less whimsical description. A trait should always be a meta function, but that is, obviously, not enough. It also has to map to entities that are associated with the types on which it acts, i.e., it has a Concept as its domain and the various related Concepts and Features as its ranges. On the meta level, a trait places a Concept in relation to other Concepts, i.e., a trait is STRUCTURAL. On the object-level, a Model is related to other Models or Features. trait<Type>::neighbor_type - relates two Concepts trait<Type>::child_type - adds a Feature A policy is BEHAVIORAL. And one often uses policies in a dynamic setting, adding them in runtime. We, of course, often implicitly refer to the compile-time policies... One cool thing about traits is that some of the Features it maps to can actually be policies. This might be what makes the distinction a bit tricky, or? Look at std::char_traits, which takes a Character Concept and maps it into its various Features. Look further into the Feature of equality, i.e., the function "static bool eq(const T& c1, const T& c2)." That particular Feature, given by the trait, can be used as a policy. So, a lot of the Features (I will stop using upper-case initial letters soon...) are behaviors that are often used as policies. We use the trait as a meta function to access a policy. Simple. /David