2011/3/28 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
2011/3/27 Frédéric Bron <frederic.bron@m4x.org>:
- 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