Re: [boost] [TTI] Review

Subject: Re: [boost] [TTI] Review
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2011-07-11 18:05:06

Edward Diener-3 wrote:
> 
> 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&lt;T, int&gt;; [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.
> 

OK, I see. I remember you mentioned about MEMBER_TYPE in replying to my
review and that is why you wanted to keep the non-composite member function
macros. I did read the MEMBER_TYPE docs. I think I understand the issue but
I need to think about it more.

I will let you know.
--Lorenzo

--
View this message in context: http://boost.2283326.n4.nabble.com/TTI-Review-tp3658414p3660989.html
Sent from the Boost - Dev mailing list archive at Nabble.com.