Boost logo

Boost :

From: Noah Stein (noah_at_[hidden])
Date: 2001-11-29 14:14:47

> -----Original Message-----
> From: austern_at_[hidden]

> Second, and this might expose a real philosophical difference
> (perhaps a misunderstanding on my part), Andrei's names are
> names of actions, not things. I realize it's possible to
> think of metaprogramming classes as higher-order functions,
> but I still feel slightly uncomfortable giving a class a
> name that connotes a function; I think of a class as something
> that is, not something that does.

Unfortunately, C++'s metaprogramming facilities require classes whose
semantics are does, not is. MPL could not implement its algorithms as
anything other than classes because it deals with types as values, something
disallowed by functions. Classes also must be evaluated at compile-time
whereas functions are not strictly required to be optimized, so some
evaluation could be postponed until run-time.

This might sound a little goofy, but I like the simile: the functionality of
C++ classes are undergoing a revolution that light experienced in the
physics community a century ago. Just as light is both a particle and a
wave, C++ classes are both types and functions. Although I agree that in
this specific case, Andrei is modelling an is (a meta-version of an integer
or type), in the general case, some classes exist almost soley as functions.

If C++ had a facility for functions to operate on types (and I really wish
it did), classes could return to modelling a stricter "is"-ality. After
all, it would be much prettier to write something along the lines of:

typename If(bool sel, class ctrue, class cfalse)
        return sel? ctrue : cfalse;

But C++ doesn't, at this time, offer such a facility. Until such time as it
does, there will be classes that strongly exhibit function semantics. As
such, I think it would be a poor idea to name such a class something that
seems an is when it is much more of a does.

-- Noah

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