Boost logo

Boost :

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-07-26 22:07:26

Mat Marcus wrote:
> Aleksey> It shouldn't. Just remember that it's a class, not a
> class template - that's
> Aleksey> the most important point (it should be easy, since
> "class" is in the name
> Aelksey> here :).
> One more try...
> RIght, I am aware that it is a class. I have no problem
> remebering what it does. I am trying to discuss pissible
> improvements in what the name suggests to the user.
> One of the MPL's strenghts is that it provides a language for
> metaprogramming. My intent in suggesting alternate names
> (quoted metafunction, metafunctor,...) is to try to help
> ensure that the language is in the domain of the user as
> opposed to the implementor (a DSL as opposed to an ICCL).
> The phrase metafunction class suggests an
> implementation detail to me.

It suggests _the form_. The form is the only difference between metafunction

    template< typename T > struct f
        typedef T type;

and metafunction class

    struct f
        template< typename T > struct apply
            typedef T type;

> Or even worse, it can be misread
> as "the class of the metafunction".

As I am not a native speaker, I cannot say how much it is a problem :). We
can always spell it with a hyphen, like many other terms in the standard:


> Why is the fact that it is a class and not a class template
> the most important point?

Because it immediately suggests you the metafunction's form.

> To me the most important point is the the fact that this form
> of metafunction wrapping is what enables higher order
> metafunctions, i.e. this is how one metafunction can be
> returnedfrom another.

That's somewhat a secondary knowledge - after you know the form of a
metafunction, you know what you can do with it.

> You could argue that this same principal is captured at
> run time in the distinction between the word "function"
> and the word "function-object" or "functor". I was looking
> for a name which stressed this role, rather than
> the (important) implementation detail that this is a class.
> By the way, for the record, as evidenced by my comments and
> MPL tutorials in the past, I think MPL is a fine piece of
> work and I vote for formal acceptance into boost.

Mat, I appreciate your thoughts and suggestions. I am just not convinced
(yet) that the current vocabulary is such a poor fit.


Boost list run by bdawes at, gregod at, cpdaniel at, john at