Re: [boost] [TTI] Review

Subject: Re: [boost] [TTI] Review
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-07-18 13:51:30

On Sun, Jul 17, 2011 at 10:07 PM, Gregory Crosswhite <
gcross_at_[hidden]> wrote:
[...]

> 2) I strongly think that "CREATE_METAFUNCTION_FOR" (or something similar)
> should be inserted into all of the macro names because otherwise they strike
> me as being misleading. If I were not familiar with this library and I saw
> the macro BOOST_TTI_HAS_TYPE(X) in someone else's code, I would be confused
> because the name of the macro makes it sound like it is asking if X has some
> type even though the result doesn't seem to be used.  By contrast, if I saw
> the macro BOOST_TTI_CREATE_METAFUNCTION_FOR_HAS_TYPE(X), it would be
> immediately clear to me that the purpose of this macro is to create a
> metafunction.
>
> I say this based in part on my own experience.  When I was learning how
> this library worked I started by skimming through the documentation to get a
> feel for what was going on, and the macro names confused me because I
> couldn't tell what they were actually doing.  I did eventually figure this
> out when I read through the documentation more closely, but if they had
> names following the convention I am recommending then I would have
> immediately understood what they were doing.
>
> Although my proposed change would require additional typing (though
> unlikely not much, since I suspect most people are like me and just copy and
> paste from a template), I think that the benefit of improving the clarity
> would be well worth it.
>

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?

> 3) I wonder if it would be better to instead of giving the metafunctions
> names such as has_type_X, it would make more sense to put them in their own
> namespace so they they would be referred to as for example has_type::X.
>  This would save use from having to use macro pasting to compute the
> metafunction names,

Agreed.

> 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?

>  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.  AFAIK,
the current metafunction-generating macros also must be invoked at namespace
scope; and, separately, I believed someone thinks it is a valid use case to
generate metafunctions at class scope (a workaround, though, would be to
generate the metafunctions in a detail namespace and use metafunction
forwarding within the class).

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 :/

> To be clear, point #3 is just me pondering other possibilities to invite
> discussion, and should not be considered a necessary change that needs to be
> made.
>

I think these are valid ideas to bring to the table.

- Jeff