On 7/18/2011 1:34 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Sun, Jul 17, 2011 at 3:18 PM, Edward Diener<eldiener@tropicsoft.com>wrote:
On 7/17/2011 4:15 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Sun, Jul 17, 2011 at 12:35 PM, Edward Diener<eldiener@tropicsoft.com**
wrote:
On 7/17/2011 2:22 PM, Jeffrey Lee Hellrung, Jr. wrote:
Well, if the naming scheme is simple (I think it is), I don't think we
have to worry about the metafunction provider nor the metafunction user not understanding the naming scheme. Have users been requesting these GEN macros? Are the GEN macros targeted toward the metafunction provider (who should know what identifiers he's injecting into the namespace) or the metafunction user (who will need to read documentation either way to get the name of the metafunction)? I don't really see the point, and I now refer you to my comment about "less is more" at the top.
The GEN macros are targeted at the metafunction user. If people really feel it is easier reading the documentation and looking at the way that metafunction names are generated than to just repeat the metafunction macro, add _GEN to the end, and pass it element name to automatically generate the metafunction name, I may remove the GEN macros. I still think that using the equivalent GEN macro for each metafunction macro is a nice and easy way to get the refer to the name of the metafunction for each metafunction macro.
They'd have to read the documentation to figure out how to use the GEN macros, too :) Also "reading the documentation and looking at the way that metafunction names are generated" is 13 words worth work, while "repeat the metafunction macro, add _GEN to the end, and pass it element name to automatically generate the metafunction name" is 20 words worth work, so the former is by far easier than the latter :)
I thought it would be easier, given let's say macro
BOOST_TTI_HAS_STATIC_MEMBER_**FUNCTION(name),
to refer to the metafunction name as
BOOST_TTI_HAS_STATIC_MEMBER_**FUNCTION_GEN(name)
than to remember it is:
'has_static_member_function_**name'.
I admit I can be wrong about this but I really, really do not see what harm those GEN macros can cause for those who want to use them instead.
If the GEN macros are primarily for the metafunction *users*, you're really taking up the burden that should be carried by the metafunction *providers*.
By metafunction users I mean programmers using TTI in their metaprogramming along with MPL, type traits, and such.
It would be the metafunction provider's job to ensure their users know their API. The metafunction user may not even know or care about the existence of the TTI library (they should, of course, but I think it's a reasonable possibility).
And, sorry, I don't see how one is easier to remember than the other :/ Just take the part of the macro after BOOST_TTI_, lowercase it, and append _'name'.
Actually in one case this is currently not followed ( he looks up aghast <g> ). The current BOOST_TTI_VM_HAS_TEMPLATE_CHECK_PARAMS generates the same metafunction name as BOOST_TTI_HAS_TEMPLATE_CHECK_PARAMS, which is 'has_template_check_params_' instead of 'vm_has_template_check_params_'. My reasoning for this was that the non-variadic macro and variadic macro version did the same thing. But this anomaly will go away with the new combined BOOST_TTI_TEMPLATE macro.
I mean, I thought one of the points about the automatic name generation is so people *don't* have to think about the name of the metafunction...
True.
You're giving users 2 different ways to do the same thing. One way you don't really have any choice to give (the user can just use the name of the metafunction directly), and I just don't see the other (the GEN macros) offering any compelling advantages. I think this is laying the groundwork for confusion.
I acknowledge I provide two ways, but I do not think confusion is involved. Even the process of taking a macro name, dropping BOOST_TTI_, lowercasing the rest, and adding _name may seem laborious to some to remember. Can't you conceive that it might be easier for the end-user to use the equivalent _GEN macro. I found it easier when creating the examples so surely there are others who might like that idea.