Re: [boost] [tti] review

Subject: Re: [boost] [tti] review
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-07-17 20:21:46

On 7/17/2011 6:46 PM, Jeffrey Lee Hellrung, Jr. wrote:
> On Sun, Jul 17, 2011 at 2:48 PM, Nathan Ridge<zeratul976_at_[hidden]>wrote:
>
>>
>>> On 7/17/2011 4:10 PM, Edward Diener wrote:
>>>
>>>> I agree with Jeff's suggestion that the matching metafunction should
>> take a metafunction that defaults to is_same rather than always testing for
>> type equality (and now I see why he was also suggesting that in the Type
>> Traits Extension review :).
>>>
>>> I will look further into adding this but I strongly feel that I should
>>> not drop the simple functionality currently provided, where the end-user
>>> can just pass an actual type.
>>
>> As a casual Boost user, I would welcome this. I would find TTI very
>> useful, but I do not know MPL beyond the very basics, and I'd rather not
>> have to learn it just so that I can use TTI. I think others may be in
>> the same position.
>>
>
> My initial response is, grab a beer and go learn about Boost.MPL lambda
> expressions, you'll be happy you did (at worst, you're +1 drunk beer).
>
> Okay, my secondary response:  I don't think it's really that bad to write
>
> has_type_xxx<  T, boost::is_same<  boost::mpl::_1, U>  >  // my proposed query
>
> rather than
>
> has_type_xxx<  T, U>  // current query
>
> (a)  How often do you *really* want to check that T::xxx is precisely U?  I
> think, much more frequently, you'll just want has_type_xxx<T>.  And I'm
> *not* proposing to get rid of *that*.
> (b)  To me, the former states more explicitly how U ties into the query.
> (c)  With the current has_type_xxx semantics, it's going to get onerous one
> metaprogramming day when boost::is_same<  boost::mpl::_1, U>  just isn't want
> what you want.  You want to check if T::xxx is an object type.  Or whether
> it's const-qualified.  Or any of a number of other properties in
> Boost.TypeTraits.  Or :: gasp :: whether T::xxx itself has a nested type yyy
> :)

I get the idea. One should be able to create one's own metafunctions for 
checking nested types and whatever introspected or non-introspected 
properties of the type one can devise as part of the library interface. 
Of course one can do that in discreet steps now ( just typedef the type 
and use TTI, type traits, or your own metafunctions against it ), but 
one extended interface is probably better. I just want to make sure this 
fits in well with everything else and think about its ramifications and 
how best it can be used with everything else.

>
> Given that TTI is a "metaprogramming library proposed for Boost", I don't
> really see any issues (in theory) with TTI making good use of a library
> called "Boost Metaprogramming Library" (aka, Boost.MPL).

That is a bit of an unfair dig. Obviously I am using plenty of MPL in 
the library, but not enough of some parts of it which you are suggesting.

Remember though, for the MPL non-expert I still want to make the library 
useful so simpler interfaces are still my goal while adding 
functionality for the experts.

>
> Honestly, though, it did take me a few reads to dissect the nuances of the
> Boost.MPL "Metafunctions" section, specifically the subsections "Invocation"
> and "Composition and Argument Binding".  Fortunately, I believe only a very
> small part of that is necessary to effectively use my proposed change to
> HAS_TYPE.  You can get a lot of mileage out of just knowing about and using
> Boost.MPL placeholder expressions like boost::is_same<  boost::mpl::_1, U>.
> I know *I* did for a long time and I just accepted the "magic" that went on
> behind the scenes that made them work until I mustered up the courage to
> really delve into the documentation.
>
> I think if TTI just added a couple of examples showing Boost.MPL placeholder
> expressions in action, everything would be fine.

I do show placeholder expressions when using the nullary metafunctions 
but I did not appreciate boost::mpl::lambda enough in allowing the 
end-user to build metafunctions taking metadata. I will revisit it. Thanks !

Eddie