Subject: Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-04-30 10:35:56
2011/4/29 Henrik Sundberg <storangen_at_[hidden]>:
> On Fri, Apr 29, 2011 at 7:59 PM, Joachim Faulhaber
> <afojgo_at_[hidden]> wrote:
>> 2011/4/29 Ivan Le Lann <ivan.lelann_at_[hidden]>:
>>> 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
(1) cross library naming consistency
(2) systematic composition
(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.
-- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk