Re: [boost] [Boost-users] TTI library updated in the sandbox

Subject: Re: [boost] [Boost-users] TTI library updated in the sandbox
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-02-06 20:57:35

On 2/6/2011 7:21 PM, Dave Abrahams wrote:
> At Sun, 06 Feb 2011 17:44:02 -0500,
> Edward Diener wrote:
>>
>> On 2/6/2011 4:14 PM, Dave Abrahams wrote:
>>> Couple o' things:
>>>
>>> On Sun, Feb 6, 2011 at 12:39 PM, Edward Diener<eldiener_at_[hidden]>   wrote:
>>>> Features of the update include support for the older gcc 3.4.2 and 3.4.5,
>>>> finer-grained introspection for the basic macro metafunctions, documentation
>>>> examples, better and tighter design, and better use of Boost MPL methodology
>>>> ( metafunctions are now passed as lambda expressions and metafunction
>>>> globbing has been removed from the two metafunctions where it previously
>>>> existed ). You can view the changes in the History section of the
>>>> documentation.
>>>
>>> FWIW, passing lambda expressions instead of metafunction classes is a
>>> trade-off: it's more expressive, but will lengthen compile times.  For
>>> the implementation of a boost library, it's probably better to err on
>>> the side of speed.
>>
>> I could create metafunction classes for use instead of having the end-user use
>> placeholder expressions. Is that what you are suggesting for better compiler
>> speed ? It should be easy enough to do. I was influenced by your MPL book and
>> how easy it is for the end-user to use placeholder expressions.
>
> Maybe I misunderstood you.  I took you to be saying that you were using
> placeholder expressions in the library's implementation.  Supporting the user
> who wants to pass placeholder expressions is a good idea.  Using metafunction
> classes in your library's implementation is also a good idea.

Above in my blurb for the library I am writing "lambda expressions", 
which can support an end-user who uses either a placeholder expression 
or a metafunction class ? Maybe you read it too fast and assumed just 
"placeholder expressions" instead.

I do not generate a metafunction class for each of the metafunction 
macros but your comment made me realize that I can easily do so. In that 
way an end-user can either use a placeholder expression or a generated 
metafunction class to pass the macro metafunctions around. Of course 
anyone is free to create their own metafunction class also.

>
>>>> The TTI library is based on the type_traits_ext portion of the Concept
>>>> Traits Library, with improvements and additions, and also lifts
>>>> functionality, for the purposes of orthogonality, from Boost.MPL regarding
>>>> introspection of types and templates.
>>>
>>> Orthogonality in what sense?  Duplicating functionality seems like the
>>> opposite of orthogonality.
>>
>> I am certainly willing and comfortable removing from the TTI library the
>> TTI_HAS_TYPE and TTI_HAS_TEMPLATE metafunction macros, which just duplicates the
>> functionality of the corresponding BOOST_MPL_HAS_XXX_TRAIT_DEF and
>> BOOST_MPL_HAS_XXX_TEMPLATE_DEF respectively. But let me first argue for why I
>> included them
>
> I don't have any argument with the choice to include them.
>
>> and what I mean when I say orthogonality:
>>
>> 1) The functionality is complete in a single library for what the library wishes
>> to do. In this case it is to introspect the inner elements of a type. I have
>> functionality to introspect member data and functions and static data and
>> functions, and some new functionality to introspect types ( checking for the
>> actual type ) and class templates ( specifying the exact template parameters ),
>> so it seemed natural for me that I should just as well also provide
>> functionality in general for types and templates, even if it was to provide the
>> exact same functionality which is in Boost MPL. This is more a situation of
>> completeness than orthogonality, but I felt that providing all of the
>> functionality the library promises was more important than duplicating the MPL
>> functionality. And of course the duplication code-wise is just minimal since I
>> am not recreating the macros which constitute BOOST_MPL_HAS_XXX_TRAIT_DEF and
>> BOOST_MPL_HAS_XXX_TEMPLATE_DEF but just using the MPL macros internally and
>> delegating to their already existing functionality.
>>
>> 2) For the nullary type metafunctions in my library I have corresponding type
>> and template functionality, to be used where the types are nullary
>> metafunctions. It would have felt odd, in the sense of the nullary type
>> metafunctions being orthogonal in functionality to the macro metafunctions, not
>> to also have the same type and template functionality in the macro
>> metafunctions.
>>
>> 3) I wanted the naming I used to be consistent with the other names in the
>> library. So instead of BOOST_MPL_HAS_XXX_TEMPLATE_DEF I have TTI_HAS_TEMPLATE,
>> instead of BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF I have TTI_TRAIT_HAS_TEMPLATE,
>> instead of BOOST_MPL_HAS_XXX_TRAIT_DEF I have TTI_HAS_TYPE and instead of
>> BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF I have TTI_TRAIT_HAS_TYPE. This sort of ease
>> of use, because the naming is consistent, is important to me when I think about
>> design for an end-user. Of course the documentation can tell the end-user to use
>> the already existing MPL macros to get type and template introspection instead
>> of providing my own set that does the exact same thing and just reuses the MPL
>> functionality. But I felt it more natural to provide my own.
>>
>> I hope you know that there is no attempt being made to create the TTI_HAS_TYPE
>> and TTI_HAS_TEMPLATE metafunction macros without acknowledging that I am just
>> lifting this from the MPL library. It is in the description when I post on this
>> NG and it is in the documentation in the Acknowledgments section. I would be
>> glad to put it anywhere else. At the same time I can remove it easily enough
>> from the TTI library but I think in that case it would be less complete as a
>> compile-time introspection library if I did.
>
> Sorry, that part was tl;dr'd.
>  I'm just pointing out that using the term
> "orthogonal" doesn't make much sense on the surface here, and if it requires
> that much explanation to get it to make sense, maybe you should choose a
> different word.

OK. Perhaps I should write "for the purpose of completeness" instead. 
Orthogonality, as in 2) above, was one part of why I chose to include them.