Re: [boost] [function types] Review

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-19 16:19:21

Hi Jonathan,

thanks for your response! My second reply to your review was sent almost 
simultanously...

Jonathan Turkanis wrote:
> Tobias Schwinger wrote:
> 
>>Hi Jonathan,
>>
> 
> 
>>>Next, function_type_signature is too complex; it has too many
>>>members, and their specifications are hard to understand. I would
>>>like to see separate metafunctions which take a function type and
>>>return
>>>
>>
>>This impression come from the fact that the documentation is
>>currently way too weak, especially at this point.
>>
>>The primary interface of this class template is not to use most of
>>these type member and use this class as an MPL Sequence (I'll cite a
>>section of previous review discussion, which I hope explains this in
>>more detail).
>>
>>Most of these members are for optimization (saving template
>>instantiations) so I vote for efficieny and not putting them into
>>wrappers. Even though using the members of 'function_type_signature' directly
>>is pretty close to the gory details, I don't think it should be an
>>implementation detail.
> 
> 
> <snip citation>
> 
> I still don't quite understand it. Even if all the work is done by
> function_type_signature, can't you give it a more user-friendly interface -- 
> perhaps a simple wrapper which hides the 'advanced' members? I will admit I
> haven't put a long time into studying 'function_type_signature'; my comments
> basically just reflect my impression that 'function_type_signature' is strange
> and complex.

I really believe it's bad documentation that gives you this impression.

Some members can't be hidden because they make up the MPL-Sequence concept
('type', 'tag').

Other members provide essential information: 'kind' and 'representee'.

'types' is for optimization (not going through the decoration).

So the only member I could hide is 'arity', I guess.

Probably I should clearly point this out in the docs. By coloring, for example.

>>Btw. I prefer the term 'parameter' over 'argument' in this context,
>>because a (formal) parameter constraints the argument (which is also
>>called an actual parameter). I.e. (translated Standardese) the
>>argument is what is passed for a parameter.
>>I know e.g. 'std::unary_function::argument_type' -- but this is not
>>exactly the same (I interpret it like: "please give me an argument of
>>this type").
> 
> 
> I, too, try to maintain the distinction between parameters and arguments. I'm
> not sure it's decisive here, though, since I usually think of a parameter as
> comprising a type *and* a formal name.
> 

An interesting way to look at it!

Doesn't entirely convince me since the argument only exists at the call site...

And because it's all about types, anyway - my thinking was something like: "You 
can't know the argument's type - you can only know the one of the parameter".

>>>Next, it's too hard too keep track of all the different tags, esp.
>>>remembering the order of the components of the names. Why not have a
>>>few atomic tags, and
>>
>>I like the idea of atomic tags to query aspects instead of full
>>combinations...
>>
>>
>>>let user's combine them via inheritance? E.g.,
>>>
>>>    struct const_tag { };
>>>    struct volatile_tag { };
>>>    struct reference_tag { };
>>>    struct variadic_tag { };
>>>    struct stdcall_tag { };
>>>
>>>    struct my_tag :
>>>         reference_tag,
>>>         stdcall_tag,
>>>         ...
>>>       { };
>>
>>..making this work with inheritance, in particular, might be
>>inefficient. though (internally these are just MPL Integral Constant
>>bit masks).
> 
> 
> It involves an extra level of indirection. However, I think it could be done in
> a way that adds only a miniscule amount of compile time when using the built-in
> tags.
> 

Not entirely convinced design-wise either because it's quite error prone.

I like your idea of banning the tags from the primary interface, entirely - and 
adding "aspect tags" only for querying.

Most cases of synthesis can work "tagless" by swapping the 'Tag' and 'Types' 
parameter of 'function_type', defaulting to 'plain_function', as described in my 
second reply to your review.

>>>You could define a bunch of convenience tags for common cases, but
>>>people wouldn't be required to learn them. This is what the
>>>iostreams library does.
>>
>>This is a bit opposite to the suggestion to remove the dominant role
>>of tags...
> 
> 
> I don't see how this is opposite.
> 

We already put the convenience cases in seperate metafunctions, don't we?

Having "atomic tags" (or let's call them "aspect tags") for querying, 
cv-qualification as part of the class type, common case metafunctions we'ld 
barely ever need to use them.

My next post will be a summary of what I think could be a reasonable synopsis 
(based on review comments and on my own experience from having used the library 
in several different places now).

Regards,

Tobias