|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-11-09 19:27:42
Eric Friedman <ebf_at_[hidden]> writes:
> David Abrahams wrote:
>
>> Eric Friedman <ebf_at_[hidden]> writes:
>>
>>>While some of the names are a bit longer, I feel the changes are
>>>beneficial to the library.
>>>
>>>I will soon update the documentation to reflect these changes.
>> FWIW, I'm a little sorry I planted the "make_" prefix in your mind.
>> It's usually only used for runtime functions, i.e. object generators
>> (http://www.boost.org/more/generic_programming.html#object_generator).
>
> I was worried about confusion that might result from simply calling
> the metafunctions 'recursive_variant' or 'variant_over'. Though
> attempting to instantiate these types directly (rather than their
> exposed ::type) would immediately lead to an error, I feel it might be
> less than obvious to the user why the error has occurred.
>
> That is why I chose the make_XXX names. My intention was to echo names
> such as mpl::make_identity.
At some point users need to learn to deal with the metafunction idiom
or we're going to be adding make_ to the beginning of every
metafunction name.
> From the link you sent, it seems like the recommended names would be:
>
> recursive_variant_generator
> variant_over_generator
> ...and so on
That's old-school generic programming. New-school metaprogramming
makes type generators into "normal" entities by calling them
metafunctions.
> I'm not sure these names are too obvious or clear, and they certainly
> are ugly.
>
> So I think keeping the make_XXX names is a good idea. What do you think?
I guess I've said everything I have to say about it.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk