On 7/17/2011 6:46 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Sun, Jul 17, 2011 at 2:48 PM, Nathan Ridge<zeratul976@hotmail.com>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