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

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
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