|
Boost : |
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
> 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.
>
> 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
consistency reasons.
"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