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
>>>> 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
>>> 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.
>> 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
>> C++ standard uses, not the name I like).
>> BTW, still from Stroustrup C.12 (page 853) there exist a composite form
>> 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::*> // 
>> Instead of:
>> has_number<T, int> 
> Your editor messed things up, so I assume you meant:
> 'has_number<T, int>; ' just above.
> The problem is that your preferred syntax  does not allow the result
> from MEMBER_TYPE to be passed separately as a single type, whereas 
> 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
>> (my comment #9) and for consistency I would only provide  (not )
>> 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.
-- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk