Boost logo

Boost :

From: David Bergman (davidb_at_[hidden])
Date: 2004-04-02 12:20:59

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? ;-)

> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at