Re: [boost] [TTI] Review

Subject: Re: [boost] [TTI] Review
From: Gregory Crosswhite (gcross_at_[hidden])
Date: 2011-07-18 14:22:41

On 7/18/11 10:51 AM, Jeffrey Lee Hellrung, Jr. wrote:
> I think this is a valid concern.  For comparison, the introspection macros
> in Boost.MPL (which, I think, were part of the inspiration for TTI) are
>
> BOOST_MPL_HAS_XXX_TEMPLATE_DEF
> BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF
> BOOST_MPL_HAS_XXX_TRAIT_DEF
> BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF
>
> I kind of like the _DEF suffixes, e.g., maybe we could consider something
> like BOOST_TTI_HAS_TYPE_DEF, etc., for the metafunction-generating macros?

While I would personally prefer to have the prefix/suffix be a bit more 
verbose to make its meaning more explicit, if that is the convention 
that MPL uses then it probably makes the most sense to adopt it for TTI 
as well.

>> and would also have the advantage of addressing Lorenzo's concern that a
>> double-underscore might inadvertently be put in a type name.
>
> Agreed; but I'm not sure how much of a concern this is.  How many class
> authors do you know use a leading underscore for any of their (logically)
> public members?

I agree that in practice it is unlikely to be much of a concern.

>>   However, I do not have enough experience here to get a full sense of the
>> design implications of choosing this convention over the current convention.
>>
> To be sure, it precludes generating metafunctions at class scope.

Good point;  I hadn't thought of that.

> Another possibility is to hide the actual name of the metafunction by using
>> a macro to access it.  If my recommendation to insert
>> "CREATE_METAFUNCTION_FOR" in all of the macro names is followed, it would
>> free up the current macro names to be used to refer to the metafunction.
>>   That is, rather than code looking like
>>
>>         BOOST_TTI_HAS_TYPE(X)
>>         boost::tti::has_type_X<T>::...
>>
>> it would look like
>>
>>         BOOST_TTI_DECLARE_**METAFUNCTION_FOR_HAS_TYPE(X)
>>         BOOST_TTI_HAS_TYPE(X,T)::...
>>
>> which would have the advantage of hiding the exact name and location of the
>> metafunction as an implementation detail.
>>
> I don't think we should be hiding the exact location of the metafunction
> entirely, as we want to prevent name collision when, say, 2 libraries
> attempt to generate the same metafunction from different namespaces.
>
> And, to be sure, it would probably be better to just generate the name only
> of the metafunction: BOOST_TTI_HAS_TYPE( X )<T>::...  Otherwise, you quickly
> run into (unnessary) complications when T is a template instantiation with
> commas in it.
>
> I don't think this is a bad idea necessarily on any technical grounds (yet),
> but I do think it's a bad idea on aesthetic grounds :/

Fair enough.  :-)

Cheers,
Greg