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

From: Mat Marcus (mat-boost_at_[hidden])
Date: 2003-10-09 21:52:30

[snip]

Mat:
>> 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.

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

Mat:
>> Hmm. Good question.

Dave:
> The usual trick is the same one used by iterator_traits:

(Incidentally, I'd like to see iterator_traits broken up into free 
generic metafunctions too.)

> the default
> implementation (unspecialized version) dispatches to some member, for
> convenience.

Yes, of course. This is a natural idea. One problem that I've seen
with this technique is that sometimes would-be generic
(meta-)algorithm authors forget to indirect through the traits class.
Maybe it would be a service when providing a library that works using
such indirection to also provide archetypal instances with no nested
data and appropriate specializations for algorithm authors to test
against. IIRC the boost concept lib employs the same technique.
 In any case I think this is the right track. It seems that today
various libs, MPL included, may place too many constraints on their
collaborators. Instead of assuming that a quoted metafunction, er
excuse me, metafunction class ;-) has a nested apply<> why not use a
level of indirection and have it adhere to a metaconcept instead. E.g.
maybe its enough to require the concept that
meta_apply<meta_function_class>::type is utterable and has the corect
semantics. Then libs wouldn't have to be rewritten to internally
follow designated naming conventions. Instead they could model the
required concepts (or is that: metamodel the required metaconcepts)
generically by providing certain free metafunctions. You could even
have headers such as functoid_as_meta_function_class.hpp following
boost::graph's vector_as_graph.hpp (except avoiding traits) example so
that the functionality could be added in layers, paying as you go. I
am tempted to apply these heuristics to boost:: and std:: and see how
various generic rewrites might look. The s/OO/generic/g rule would be
something like, "whenever a nested type (or traits, which technically
also use nested types) or a nested member (e.g. member function or
member variable) is used, add a level of indirection so that
collaborators have a chance to supply this function externally".

somebody-stop-me-soon-please-ly,
Mat