Re: [boost] [GTL] redesign checked into sandbox

From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-05-10 05:59:49

>>1. Prefer metafunctions in the point concepts requirements
>>   over traits classes, or I'm afraid the traits will get huge.
>
> If the traits are huge the abstraction is being made in the wrong place.
> A good abstraction is a min-cut in a graph of dependencies.  A huge
> number of metafunctions seems equally bad to me.  Instead the goal
> should be to minimize the number of traits/metafunctions required to be
> understood/specialize by the user.

I know the principle of avoiding blob traits, as exposed in Abrahams
and Gurtovoy's book. But I think it doesn't apply here just because
the traits in question is *way* short. A type, a value, an accessor.
And most algorithms need all of them. Does it really make sense to
scatter them into several metafunctions??

>>2. Put your concept mapping functions in a namespace rather
>>   than a class (do it like like Fusion does).
>>   Namespaces seem to provide a lot more flexibility, and
>>   the syntax is a LOT cleaner.
>
> I am considering the implications of your suggestion.  It could be that
> it can be made to work, but I'm not clear on how overloading functions
> in a namespace is preferable to specializing a struct.  It seems that it
> is more prone to compiler errors related to overloading ambiguity caused
> by bad user code and unfortunate combinations of user code.  With the
> traits there is no chance for ambiguity.

I agree with Luke on this point, I'm afraid about nightmares that
overloading ambiguities could bring to the user. However, I will
consider doing a few tests to see the actual consequences of what you
propose.

>>3. Provide separate headers for each metafunction.
>>   This allows users to fucus on metafunctions that matter.
>
> I am doing this already, though there is only one metafunction that
> matters right now; the one that maps the user type to its related
> concept.

Same remark as above: one metafunction and one separate header of each
of the 3 properties needed, I wonder if it's not a bit overkill...

>>4. Make all requirements explicit in the concept class. This
>>   way I can look at the concept code and see what they are.

Aren't the requirements explicit enough in the concept class I've
shown? If not, could you be more precise on what you'd like to see
more clearly specified?

Bruno