From: "David Bergman" <davidb@home.se>
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? ;-)
Not entirely.
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.
Good.
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.
So you're saying that a traits class cannot have behavior? You're saying that, for example, std::char_traits<T>::length() means that std::char_traits is not a traits class? While I agree that there should be little behavior in traits classes as a rule, if that behavior is peculiar to the traits class (specialization of class template, typically), then it is reasonable. I say that because you can count on the consistency of that behavior and the specific behavior is based upon the combination of the traits class and the type for which you want the traits.
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.
Again, I take it that you're excluding behavior, with which I disagree.
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...
I just don't find this compelling. Gennadiy was trying to ask before about specific smart_ptr policies that don't have behavior. The implied question is that if they don't have any behavior, why are they called policies? Conversely, I recall that he was asking about some so-called traits classes that have behavior; were they wrongly classified?
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.
I see what you mean, but it doesn't fit prior art, at least not to me. For me, a type that unequivocally associates information and yes, even behavior, with another type is a traits class. A type that can be injected via template parameter to control the behavior of a template is a policy. The distinction is whether all code has equal access to the information (traits) or whether only a specific template has the information (policy). Traits are characteristics associated with another type. Policies are imposed by any client of the template using the policy. (BTW, you might want to shorten your lines a bit so they don't get rewrapped after being quoted just a couple of times.) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;