RE: [boost] Re: Policy or Trait?

From: David Bergman (davidb_at_[hidden])
Date: 2004-04-02 16:17:52

Rob wrote: 

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

I kind of assumed you would not ;-)
 
> > 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.

Yes, so we should not have any problem deciding whether a "thing" is a
policy or not. A good first step.

[snip] 
> So you're saying that a traits class cannot have behavior?

Yes, that is what I am saying, weird as it might sound... Not "have"
behavior, but certainly map to... yes, the distinction is partly
philosophical, I admit that.

> You're saying that, for example, 
> std::char_traits<T>::length() means that std::char_traits is 
> not a traits class?

No, in my twisted world view 'std::char_traits' is a trait (template) class
manifesting some features of the Character concept. One of the features is a
behavior, 'length.'

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

It might be reasonable to let the trait (template) class map to certain
behavioral features of the concept, yes.

Again, the crucial part is that trait classes realize relationships and
features found in the concept model, where you get the *actual*
correspondents (types, values, and, yes, behavior) of the model provided as
type parameter.

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

Ok, makes sense. If that kind of behavior is expected for all models of a
concept, it might make sense to realize it via a trait, such as
"std::char_traits<C>::eq(const C& c1, const C& c2)."
 
> > 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.

No, I am not excluding behavior. Some of the features in the Feature Model
might be behavior, but when using GP in C++, one should use syntax as
triggering the behavior, without going through traits, in my very humble
opinion. That is, in C++ we define a number of pseduo-syntactical
constructs, such as "The concept Comparable has an operator '<'" and use
that '<', without going through a trait. Had C++ been a true GP-embedding
language, like Haskell, we could have coded that constraint directly.

So, we use

        template<typename T>
        T min(const T& t1, const T& t2) {
                return t1 < t2 ? t1 : t2;
        }

instead of

        template<typename T>
        T min(const T& t1, const T& t2) {
                return rob::comp_trait<T>::less(t1, t2) ? t1 : t2;
        }

[snip]
> 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?

I missed that sub thread, but when the user code, such as a smart pointer
framework, expects something to happen, in delegating to a policy object,
even the absence of behavior is behavior... This touches at the focus of
David A., in the use of the construct as the defining point.

> Conversely, I 
> recall that he was asking about some so-called traits classes 
> that have behavior; were they wrongly classified?

I know that a lot of non-trait classes are called "..._traits." So, yes,
some of them are wrongly classified, since a lot of people, even the highly
skilled ones at certain committees, have used policy and trait
interchangeably.

[snip]
>> 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.

I agree, sadly.

> For me, a type that unequivocally associates 
> information and yes, even behavior, with another type is a 
> traits class.

For me, the trait concept is more tighly associated with a GP feature model
and conceptual network, but I could swallow that view point, being more
succinct and more down-to-earth C++-ish ;-), and change my semantics
accordingly. Clean enough, in other words. The important, perhaps
philosophical, issue is your use of "associated ... behavior," which is
totally aligned with my view, i.e., *not* 

> A type that can be injected via template 
> parameter to control the behavior of a template is a policy.

Yes [but in my world of development there are also runtime policies,
implemented via objects.]
  
> The distinction is whether all code has equal access to the 
> information (traits) or whether only a specific template has 
> the information (policy).

Hmm, but what happened to the nice injective property of policies of which
you (and I) talked?

> Traits are characteristics associated with another type.

Ok.

> Policies are imposed by any client of the template using the policy.

So, you do share David A.'s view, that the usage is important?

Is it fair to say that a policy is defined by its use and a trait by its
describing characteristics of types? If so, it is fairly close to my
original DESCRIBE/ACT dichotomy... ;)

> (BTW, you might want to shorten your lines a bit so they 
> don't get rewrapped after being quoted just a couple of times.)

I will, next time.

/David