|
Boost : |
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-04-02 13:05:55
> > If user do not like default value for the trait. It's value should be
set
> > *externally* to the component definition. That is the major point I am
> > trying to prove in regards to numeric_cast design and in thic generic
> > discussion.
>
> But what about the distinction that xxx_traits<T>, a class, is
> being used as the Policy type in Foo? From Foo's perspective, it
> has a Policy which its clients can define any way they like
They sure could. Note though that this is not how basic_string is designed.
There Traits parameter used as trait collection. I am yet to see an example
of good design that rely on possibility of trait class to be used sometimes
as policy. I still couldn't find a reason to use policy parameter that could
be instantiated with trait value. It should be something that is not unique
to the type but sometimes it may coinside with some other [un]related type
trait. I guess it's possible. But it rare case that could be omitted in
basic definition and mentioned only in "special cases" clause.
> within the constraints of what's expected of the policy. By the
> same token, other code, even code within Foo can use
> xxx_traits<T> to get information. (Foo could do it regardless of
> the type corresponding to the template argument Policy.)
>
> --
> Rob Stewart stewart_at_[hidden]
Gennadiy.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk