[boost] Re: [function types] Formal Review begins today.

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-08 09:06:17

I'll have to answer this upside down:

Jody Hagins wrote:
 > On Wed, 08 Jun 2005 02:39:25 +0200
 > One of my mottos is: "If you don't want me to do it, don't provide the
 > interface."  Around here, I am known for "breaking" code the first time
 > I use it, because I seem to automatically see uses that were not
 > necessarily intended... it also explains some of the reasons I am so
 > pedantic about docs.

So I can be happy to benefit from your "quality assurance instinct" ;-).

In fact, I was (and still are) unsure if the members of 
'function_type_signature' should be documented at all.

The primary interface for type analysis (clasification & decomposistion),

     is_function_type
     function_type_arity
     function_type_result
     function_type_class
     function_type_parameter*

and all MPL-Sequence operations (called "Intrinsic Metafunctions" in its docs 
which means things as: front, back, at, ...) are built upon one single class:

     function_type_signature

Therefore, all these members have at least an internal right to exist.

I did document them "just in case", because there might be some corner-cases in 
which their use is more efficient or convenient. It seems safe to remove them 
from the documentation to me ITM, but I want to think some more about it before 
doing so. Another option could be to move their description to a comment in the 
header.

If they are kept, however, I see the documentation should be changed to make a 
very clear recommendation not to use them, unless having good reasons.

 > Tobias Schwinger <tschwinger_at_[hidden]> wrote:
 >
 >>
 >> [...]
 >>
 >
 > Hmmm.  Kinda like getting the most derived type when calling typeid on
 > an instance of a polymorphic class.  Interesting.  I'm not sure how much
 > I like that, but I'm not sure about the alternatives either...
 >

It's used internally by 'is_function_type' (to match it against the tag 
specified by the client) and by the Sequence operations (to reconstruct the type 
after the Sequence has been modified). I guess this gives you an idea why you 
get the "most specialized" tag.

 >
 >>Curious question: what's the intention behind this ?
 >
 > I dunno.  I just thought it was a possible use of the interface.
 > However, one of the thoughts was that I do not necessarily know the tag,
 > but I have a type.  Maybe something like iterating through a collection
 > of types, looking for types that are elements of the same type-tag set,
 > so that I can perform some action (like registering that type with some
 > multi-signal mechanism).

OK, let's say we want to register a whole bunch of functions. This implies that 
we are either using Fusion-tuples (or alike) or pointer (to member) non-type 
template parameters, because the type of a pointer (or reference) is not enough 
to describe a function we can call.

For sorting, a custom comparator gives you the flexibilty to define whatever 
ordering you like. A simple scenario could be something like this:
A vector of tags for the groups and a binary metafunction that compares the 
index of the first match (found by applying is_function_type) in this vector for 
each parameter as the comparator.
However, if your only criterium for sorting is the type-tag you might be better 
off with filtering, anyway.
In fact, I'm not convinced that sorting is appropriate here at all: it seems to 
me like a case for making decisions inside the iteration on a per-function basis 
on which runtime code, dispatch identifier, map entry, etc. to use (and make 
sure similar functions end up in the same pot, somehow ;-) ).

Generally, I believe there are still lots of interesting design opportunities in 
the direction of "intelligent callbacks facilities" (and the library we're 
talking about here is another puzzle piece for their implementation).

Thanks again for spending so much time evaluating my submission.

Regards,

Tobias