
On 7/11/2011 5:17 PM, lcaminiti wrote:
Edward Diener-3 wrote:
On 7/11/2011 10:56 AM, Stewart, Robert wrote:
Edward Diener wrote:
On 7/10/2011 7:59 PM, Lorenzo Caminiti wrote:
Review of Boost.TTI 2011-07-10 (Lorenzo Caminiti)
10. [NOTE] I think "member variable" is a more accepted name that "member data"-- isn't it? If so, I'd rename MEMBER_DATA to MEMBER_VARIABLE.
I can understand your preference. I will consider it.
They are called data members, not member variables, in C++. Names like "member variable" come from other languages.
I don't use "member data" generally, but to me it describes data members collectively, not singularly.
I recognize the desire to keep the prefixes alike, but I'd rather see "HAS_DATA_MEMBER" to be consistent with Standard terminology.
I agree with your remark about the normal terminology. I could have used HAS_DATA_MEMBER and HAS_MEMBER_FUNCTION but I wanted to align the names around a common beginning. That is why I chose HAS_MEMBER_DATA and HAS_MEMBER_FUNCTION. Similarly HAS_STATIC_MEMBER_DATA and HAS_STATIC_MEMBER_FUNCTION. Sometimes such mnemonic similarities ( having the same common beginnings ) is more important than other factors.
I know that this may start some long discussion about names in TTI, but here is a general suggestion to all programmers who are ever upset about names in a library, and does not just refer to TTI: if you do not like a name, just create an object-like macro for your own use which takes some name and transforms it to some other name which you like better.
Lorenzo might write the macro:
#define BOOST_TTI_HAS_MEMBER_VARIABLE BOOST_TTI_HAS_MEMBER_DATA
and you might write the macro:
#define BOOST_TTI_HAS_DATA_MEMBER BOOST_TTI_HAS_MEMBER_DATA
This is guaranteed to work without problems all the time AFAIK to transform one name to another.
My comment #10 started by asking if member variable is the common name. As it has been pointed out, it is not. From Stroustrup C.12 (page 853) "data member" is the common name so I think MEMBER_DATA is the appropriate name and the one I would like to use (this discussion is about the name that the C++ standard uses, not the name I like).
BTW, still from Stroustrup C.12 (page 853) there exist a composite form from data members, not just member functions:
typedef void (C::* member_func_type)(int); typedef const char* C::* member_var_type;
So back to my comment #11, I would like to see:
TTI_MEMBER_DATA(has_number, number)
has_number<int T::*> // [1]
Instead of:
has_number<T, int> [2]
Your editor messed things up, so I assume you meant: 'has_number<T, int>; [2]' just above. The problem is that your preferred syntax [1] does not allow the result from MEMBER_TYPE to be passed separately as a single type, whereas [2] does allow it. Please try reading my explanation in the documentation again about MEMBER_TYPE, why it is so useful, and and therefore why syntax which allows individual types to be passed should always be preferred. If, after looking at that again in the doc, you do not understand what I am getting at, i will be glad to explain it in this thread. I admit that my explanation for MEMBER_TYPE may not be the clearest and easiest to understand and in the revised doc I will be explaining it in a simpler and hopefully easier to under manner.
Again, I would only provide the composite form for checking member functions (my comment #9) and for consistency I would only provide [1] (not [2]) for data members (my comment #11).
Again if you understand MEMBER_TYPE and for what it is used, you will understand the weakness of purely composite forms in TTI. Eddie