Re: [boost] Re: Policy or Trait?

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-02 13:25:49

From: "David Bergman" <davidb_at_[hidden]>
> Rob wrote: 
> > From: "David Bergman" <davidb_at_[hidden]>
> > > 
> > > > 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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;