On Sun, Jul 17, 2011 at 10:07 PM, Gregory Crosswhite < gcross@phys.washington.edu> 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