Re: [boost] Re: Review Request: FC++

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.

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

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

Hmm. Good question.

Dogmatically yours,
Mat