Boost logo

Boost :

From: Mat Marcus (mat-boost_at_[hidden])
Date: 2003-10-09 14:40:23

--On Thursday, October 09, 2003 2:51 PM -0400 Brian McNamara
<lorgon_at_[hidden]> wrote:

> On Fri, Oct 10, 2003 at 01:54:04AM +0800, Joel de Guzman wrote:
>> David Abrahams <dave_at_[hidden]> wrote:
>> > Douglas Gregor <gregod_at_[hidden]> writes:
>> >> We've discussed this before, although I can't find a reference
>> >> to it because I believe it was an e-mail conversation. The
>> >> reason we did not name the "result" member class template
>> >> "apply" is that we envisioned function "object types that were
>> >> both metafunction classes and function objects, "and therefore
>> >> would have both "apply" (in the MPL sense) and "result" (in the
>> >> result_of sense) member class templates. For instance:
> Based on this discussion, perhaps the best choice for FC++ is...
> Rather than having each functoid type being a metafunction (e.g.
> "map_type" is a metafunction to compute the result type of the "map"
> functoid based on its argument types), instead have either a nested
> type or an external traits thingy "as_metafunction".
> Yeah; this generalizes then from FC++ to everything that supports the
> result_of stuff. I'm imagining:
> // For every type F, where F supports result_of
> metafunction_result_type_computer<F>
> is the corresponding metafunction which computes the result type
> based on the argument types. I think this is the most general
> abstraction.

Yes! At the risk of repating myself from the recent "Beyond Objects"
thread: Down with members, nested types and trais, in public
interfaces :-)
It's that darned OO mentality that's so hard to shake loose on the way
to generic design. Having the return type calculator as a free
metafunction seems like just the ticket.

> The problem, of course, is that it is not terse.

> Hmm. Is there some point in the design space here that optimizes
> all of the various considerations?

Hmm. Good question.

Dogmatically yours,

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