[boost] Re: review request: container_traits

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-05 16:03:00

Brian McNamara <lorgon_at_[hidden]> writes:

> On Sat, Oct 04, 2003 at 05:48:19PM -0400, David Abrahams wrote:
>> Brian McNamara <lorgon_at_[hidden]> writes:

> One solution, which I think is the solution you are suggesting, is to
> make individual traits:
>
>    container_value_type<C>::type
>    container_iterator_type<C>::type
>    ... // etc for each "foo"
>
> This solves both of the problems above: each type is computed
> "independently", and each trait is an MPL metafunction.  However the
> weakness here is that now we have polluted the namespace with many
> new names (rather than just one ("container_traits")), 

So use a nested namespace (?)

What I see above is a very complicated solution to a very simple
problem.  I don't think there's any need to do something creative
when we can do something that's already proven to work.

> and the conceptual-relatedness of the group of traits is no longer
> expressed by a structural grouping in the code.

Which is good because it allows non-intrusive extension.  And there
*will* be extensions.  We really shouldn't want the definition of
container_traits to get progressively more bloated as they are added.

> In order to have our cake and eat it too, I propose this:
>
>    container_traits<C>::value_type<>::type
>    container_traits<C>::iterator_type<>::type
>    ... // etc for each foo
>
> Now we reap the advantages of both solutions.  That is
>
>  - we have conceptually grouped related traits into a single traits
>    class (container_traits<C>)
>
>  - each individual trait is an MPL metafunction (e.g. 
>    container_traits<C>::value_type<>)

That's a nullary metafunction, which isn't very useful if you want to
use it in an MPL lambda expression.  Since C is already bound into it,
you can't apply it to different containers.

>  - asking for one trait (e.g. value_type) does not cause other trait 
>    values (e.g. iterator_type) to get computed
>
>  - we have only introduced one name (container_traits) into the (boost) 
>    global namespace
>
> Agree/disagree?
>
>
> Mostly unrelated to the above:
>
>> How do you express
>> 
>>         argument_type<F,_1>::type
>> 
>> with that system??
>
> No clues here; sadly I still only a tiny bit about MPL, just enough
> (hopefully!) to participate in this discussion.

Well, the answer is that you can't, unless you wrap it into a proper
metafunction... and if you're going to do that, why not just start
with a proper metafunction to begin with?  It's the same problem as
above.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com