Re: [boost] [Boost-users] [Review] Type Traits Extension by Frederic Bron - Review summary and decision

Subject: Re: [boost] [Boost-users] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-03-28 08:17:52

2011/3/28 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> Joachim Faulhaber wrote:
>> 2011/3/27 Frédéric Bron <frederic.bron_at_[hidden]>:
>> >>  - The main recurring suggestions found was the choice of
>> >>    name for the operator traits with respect to the
>> >>    standard naming, naming in proto and other boost
>> >>    libraries.
>> >>  * Frederic and a few other seems to favor the proto naming
>> >>    scheme (more or less the negate issue and the pre/post
>> >>    operator)
>> >>  * the question of a common prefix is still open
>> >
>> > What about is_callable_plus, is_callable_plus_assign, ...
>> > i.e. is_callable_xxxx where xxxx the same as in Boost.Proto?
>> >
>> > I know that is_xxxx_callable reads better but I like to have
>> > a common prefix longer than is_.
>>
>> Is there any problem related to using a short prefix like
>> "is_"?
>
> I like short prefixes when they are meaningful, but is_add/is_addition/is_plus
> means nothing.
>
> is_callable_add/is_callable_addition/is_callable_plus isn't much better
> (though using the "is_" prefix and "_callable" suffix works: is_addition_callable).
> "is_" seems to work well for some, like is_equal_to, until you realize
> that the implication is whether two types are equal, not whether the
> equality operator can be used with the two types.
>
> "can_add" works for the addition case, but works awkwardly for equality:
> "can_equal_to."
>
> "can_call_" seems to be a nice, reasonably short prefix: can_call_addition,
> can_call_equal_to, can_call_bitwise_xor, can_call_left_shift, etc.

These naming debates tend to become a little tiring. Given the names
that have been chosen in the standard and other boost libraries and a
simple and uniform semantics of these operator traits I would prefer a
naming that is simple and uniform as well.

As I stated in my review already I can live with a simple

has_xxxx
where xxxx

are most unifying names as proposed in
https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators

Best regards,
Joachim

-- 
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de