Re: [boost] Re: Formal Review: Template Metaprogramming Library (MPL)

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-07-27 03:47:45

>From: "David Abrahams" <dave_at_[hidden]>

Since this issue didn't go away by itself (leaving the current naming as it
is), :) let's approach this a little systematically. What follows is also a
little thinking out loud.

> 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.

I also understand Mat's arguments, here, about presenting the interface,
rather than implementation.

To deliberate a little on this. "metafunction" means something that behaves
as a function, at compile-time. This fits fine with templates, as you may
pass the arguments as template arguments.

To analyze the possibility of "metafunctor", "metafunction object" or
"metafunction value", which are some of the names suggested, we could then
consider what "object" at compile-time would mean. "metaobject", if you
like.

An object, at run-time, is something you may have more than one of, even
with identical state (but not the same identity). There may not be more than
one version of a class. Making more than one version of the same class, from
a template, isn't possible. To make another version, you have to change the
parameters used, which in a way changes its (compile-time) state, too. Thus,
you can't really have more than one class, which are otherwise equal, but
with different state, like you can have more than one object that is of the
same type.

Mat also suggests "metafunction object" or "metafunction value", in a later
posting. However, it's not an object or value in the C++ sense. It's a type.
You could say that in metaprogramming, the classes are objects, as he says
in a later posting, but as he also says, it's perhaps a bit of a stretch.

I think "metafunction", for the template version, and "metafunction class"
for the class version, is fine. "quoted metafunction", even though I
understand its meaning, would perhaps be less intuitive to some. Especially
people with no functional programming background.

Another thing is, as you say, for run-time programming, some may prefer
"function object" to "functor". It might be similar for compile-time
programming. That gives us... "function class", or probably better
"metafunction class", to show that it's a metafunction, not a C++ function.

That is, unless we transpose the terms, so that "meta" in front, changes
"object" to mean "class", so that "metaobject" is a class, and "metafunction
object" or "metafunctor" is a class as well. However, it could be a little
obscure, for people who aren't used to the change of meaning of "object", if
"meta" is used, as well.

You could make the same argument, saying that "metafunction" (template)
doesn't fit "function", either, as it's not a C++ function. Still, it
behaves like one. I think it's more questionable if classes behave enough as
(compile-time) objects, to warrant calling them "metaobjects".

Just to add to the suggestions, how about parallelling the run-time
programming, and have "metafunction class", with the alternative
"metafunctor"? That would parallell "function object" and "functor", for
run-time.

That may satisfy everybody, both those who prefer the "functor" form, and
those who don't.

This also is in agreement with what Aleksey says, that "metafunction class"
tells about its form. It's a class. I think this makes sense. Just as
"function object" tells about its form, it's an object. No need to make
"class" or "object" mean something different, depending on whether or not
"meta" is used in front. That could be confusing.

However, this is really all about preferences, so there's no "right" or
"wrong", here. To me, it's fine whatever is selected. It's just a name,
after all. So I leave it to those with strong opinions on the subject, to
select it.

Just my 0.02.

> As a possible compromise I will throw out "metafunction type" as a
> possibility.
> Since C++ metaprogramming is computation with types, this helps indicate
> that we have something which can be manipulated with higher-order
> functional code.

That's another possibility.

Regards,

Terje