Re: [boost] review request: addition to type_traits library ofhas_operator_xxx

Subject: Re: [boost] review request: addition to type_traits library ofhas_operator_xxx
From: viboes (vicente.botet_at_[hidden])
Date: 2010-11-20 04:15:42

Edward Diener-3 wrote:
> 
> On 11/17/2010 3:48 PM, Stewart, Robert wrote:
>> Frédéric Bron wrote:
>>>
>>>> Those names are not consistent with
>>>> boost::has_new_operator.  That is, you need to rename them
>>>> like the following for consistency:
>>>>
>>>>    s/has_operator_\(.+\)/has_\1_operator/
>>>>
>>>> The result won't be perfect.  For example,
>>>> "has_operator_divides" should be renamed "has_division_operator."
>>>>
>>>> Renaming "has_new_operator" seems more appropriate,
>>>> however.  "has_operator_new" puts "operator" and "new" in the
>>>> right order as the query is for operator new, not the new operator.
>>>>
>>>> The same discussion applies to the other traits.
>>>
>>> The question of naming has already been discussed here :
>>> http://thread.gmane.org/gmane.comp.lib.boost.devel/194625
>>
>> There wasn't much discussion.  You asked about "has_operator_less_than"
>> versus "has_less_than_operator" and I suggested that the former is more
>> consistent with C++ syntax, but that deviates from
>> boost::has_new_operator.
>>
>>> At that time, we preferred has_operator_xxx to has_xxx_operator.
>>
>> I still think its better.
> 
> I agree also. Having all the operator traits begin with 'has_operator_' 
> makes their use easier to remember.
> 

I prefer has_division_operator than has_operator_division, and yet more than
has_operator_divide.

division_operator ::= operator/()

> Alternatively I could even see putting all the operator traits in their 
> own namespace of 'boost::operators', dropping the 'operator_' in their 
> name, and allowing the end-user to surface them to just the 'boost' 
> namespace via a using declaration as they like. But then again, I am a 
> very strong supporter of namespaces and allowing the end-user to expose 
> what they want from namespaces via 'using'.
> 

Note that interfaces must be designed not only to satisfy the developer but
to improve the readability. If a namespace is used, as a user I will need to
be able to decipher that

  has_division<T>::type 

intends to be "has division operator". I will find much more clear If I have
to read

  has_division_operator<T>::type 

IMO, namespaces in this case doesn't make the code more readable.

Best,
Vicenrte
-- 
View this message in context: http://boost.2283326.n4.nabble.com/review-request-addition-to-type-traits-library-of-has-operator-xxx-tp3045936p3051361.html
Sent from the Boost - Dev mailing list archive at Nabble.com.