From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-27 08:09:01
From: "Terje Slettebø" <tslettebo_at_[hidden]>
> >From: "Terje Slettebø" <tslettebo_at_[hidden]>
> > This also is in agreement with what Aleksey says, that "metafunction
> > 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
> > "meta" is used in front. That could be confusing.
> To tie this in with what Mat said about denoting something's role, or
> function. For "metafunction class", "metafunction" tells about its role -
> it's a metafunction (compile-time function), and "class" tells about its
> form. Kevlin Henney would love this one, with his "Function follows form"
> articles. :)
No, this analogy isn't good, either. We are creating a new terminology from
scratch. "Metafunction" means a class template with a nested type named
'type.' Since we aren't calling it "metafunction class template" to reflect
the form, the "other" form should have an abstract name as well for
"Quoted metafunction" is a "metafunction" (abstract term) that has been
"quoted" (abstract term) in order to make it suitable for use in context
where plain metafunctions don't work.
> In run-time programming, it may be considered the same way, with "function
> object", where "function" is its... function, :) or role, and "object" is
> its form.
Runtime is another false analogy, we use "function object" and "functor" to
denote something that is an extension of the ordinary "function", i.e. a
"function" works wherever a "function object" is expected. (A "function
object" is an object that behaves like a function. A "metafunction class" is
a class, but it does not behave like a metafunction.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk