Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-02 11:10:48


From: "Hurd, Matthew" <hurdm_at_[hidden]>
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]
> > On Behalf Of David Abrahams
> > > Rob Stewart <stewart_at_[hidden]> writes:
> >
> Can a method call be part of a trait class? I don't think traits should

In my book, certainly.

> have anything to do with enacting behaviour (they may describe it).

I don't agree.

> If it is not clear and I see a method I think of it as policy-like. A
> collection of types and static constants and I think of it as
> trait-like.

I only think of policies as template parameters that inject
types, values, and functions to control the template. I think of
traits as standalone entities known by their names. (That's not
to say the latter can't be passed to a template to be used as the
former.)

> Traits are used to get information at compile time. Policies are used
> to modify behaviour. Traits could be used by a client to modify
> behaviour which makes them feel like a policy class, but they aren't in
> what we normally think of as a policy.

That's where we differ. In your example, the traits class is a
policy class precisely because it is passed as a template
parameter.

> If a trait is used to direct the modification of behaviour, is it a
> policy from the client classes point of view I guess... which points to
> the terminology confusion.

A traits class is always used within the implementation by its
well-known name.

> Policies can be chained, multiply inherited from or just be ordinary
> template classes with static methods, maybe such different styles should
> have different names... a chain aspect, a base aspect (MCD-like), a
> static aspect...

I don't see how being able to chain policies requires a new name.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk