From: David Abrahams (dave_at_[hidden])
Date: 2002-07-25 08:59:37
FWIW, although "functor" has fallen out of favor in the C++ world, I agree
with Mat's arguments and think "metafunctor" captures the whole thing
pretty nicely for a user. However, though I don't understand it, I respect
Aleksey's long-standing hatred for the term.
As a possible compromise I will throw out "metafunction type" as a
Since C++ metaprogramming is computation with types, this helps indicate
that we have something which can be manipulated with higher-order
----- Original Message -----
From: "Mat Marcus" <mmarcus_at_[hidden]>
> Mat>> Unfortunately, 'metafunction class' does not immediately
> Mat>> bring meta(function object) to my mind.
> 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
> 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. Or even worse, it can be misread as "the
class of the metafunction".
> Why is the fact that it is a class and not a class template the most
important point? 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. 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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk