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

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-07-25 05:24:29

Mat Marcus wrote:
> Just a few comments about naming... I know we've been over 
> this before so I won't suggest 'quoted metafunction' for the 
> general purpose name again. But 'metafunction class' really 
> doesn't click for me. Let me spend a moment guessing at why 
> you chose the name metafunction class.
> 
> <begin speculation>
> Presumably the current name tries to leverage terminology 
> familiar to the reader by making an analogy with 'function 
> object'. That is,
> 
>   function is to function object
>         as
>   meta-function is to meta-'function object'
> 
> Meta-'function object' could also be spelled metafunction 
> metaobject (by the distributive law :-)). 

No, "object" to "class" translation performed by default when you move from
run-time to compile-time :). But anyway, it's not how the terminology was
born, see below.

> And metaobjects can 
> be viewed as classes, thus the name metafunction class.
> <end speculation>

Actually, it's much more simpler: a "metafunction" is a class template, e.g.

template< typename T > struct identity
{
    typedef T type;
};

A "metafunction class" is a class that is a metafunction (e.g. a
compile-time invocable entity) (or, if you prefer, which contains a
metafunction):

struct identity
{
    template< typename T > struct apply
    {
        typedef T type;
    };
};

> 
> Unfortunately, 'metafunction class' does not immediately 
> bring meta(function object) to my mind. 

It shouldn't. Just remember that it's a class, not a class template - that's
the most important point (it should be easy, since "class" is in the name
here :).

> For such an end, perhaps the name 'metafunctor' would be better?

No, please!! :) I hate it.

> 
> Also, what ever happened to then proposal for the name ct_if?

We don't need no ugly 'ct_' prefix :). We already have one - 'mpl::'.

Aleksey