Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
----- "Joachim Faulhaber" <afojgo@googlemail.com> a écrit :
Hi Frédéric, list, (snip)
To save you some time, I have inserted my proposal as column D into the Wiki at https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames
I like those names, except "has_negate". I would have kept "has_unary_minus", in line with proposed "has_unary_plus". I also wonder if "has_negate" could be mistaken for "!" by some people. Regards, Ivan
2011/4/29 Ivan Le Lann <ivan.lelann@free.fr>:
----- "Joachim Faulhaber" <afojgo@googlemail.com> a écrit :
Hi Frédéric, list, (snip)
To save you some time, I have inserted my proposal as column D into the Wiki at https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames
I like those names,
I tend to appreciate that ;) After all column D contains my proposal. But I want to stress here again that I don't like many of them and I share many of the critiques expressed by others in this seemingly never ending thread.
except "has_negate". I would have kept "has_unary_minus", in line with proposed "has_unary_plus".
I also wonder if "has_negate" could be mistaken for "!" by some people.
I can understand this concern for example. The point here is that I have a strong preference for the choice of names, which maximizes standard and cross library naming consistency. negate is used in the standard and in Boost.Proto for entities referring to unary operator - . So according to rules 1 and 2 on https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators negate is the only choice for the naming component referring to the operator. Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
On Fri, Apr 29, 2011 at 7:59 PM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
2011/4/29 Ivan Le Lann <ivan.lelann@free.fr>:
I like those names, except "has_negate". I would have kept "has_unary_minus", in line with proposed "has_unary_plus".
I also wonder if "has_negate" could be mistaken for "!" by some people.
I can understand this concern for example.
and the has_not in has_not_equal_to sounds lite the opposite to has_equal_to (I was looking for has_not). Couldn't the bitwise_ names in Boost be marked as deprecated and live together with a new bit_ for a while? /$
2011/4/29 Henrik Sundberg <storangen@gmail.com>:
On Fri, Apr 29, 2011 at 7:59 PM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
2011/4/29 Ivan Le Lann <ivan.lelann@free.fr>:
I like those names, except "has_negate". I would have kept "has_unary_minus", in line with proposed "has_unary_plus".
I also wonder if "has_negate" could be mistaken for "!" by some people.
I can understand this concern for example.
and the has_not in has_not_equal_to sounds lite the opposite to has_equal_to (I was looking for has_not).
In technical and formal languages sometimes some awkward names emerge from systematic compositions like the concatenation of prefix has_ and the operator names some of which are composed in themselves using other prefixes like "not_". There might be conflicts between different goals, here (1) cross library naming consistency (2) systematic composition versus (3) easy to understand (4) principle of least astonishment Since we are dealing with and manipulating a formal language, I tend to prefer (1) and (2) here. I also use refactoring through textual substitution a lot. This can be done much more efficiently if goals (1) and (2) have priority.
Couldn't the bitwise_ names in Boost be marked as deprecated and live together with a new bit_ for a while?
This would be the second step before doing the first one. Unless we agree on the goal of cross library naming consistency, any depreciation strategy will be futile. Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
participants (4)
-
Henrik Sundberg -
Ivan Le Lann -
Joachim Faulhaber -
Joel Young