Re: [boost] [TTI] Review

Subject: Re: [boost] [TTI] Review
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-07-11 17:55:57

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&lt;T, int&gt; [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