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-21 12:31:28

2011/4/21 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> Joachim Faulhaber wrote:
>> 2011/4/20 Frédéric Bron <frederic.bron_at_[hidden]>:
>>
>> > I have updated the type traits extension for operators:
> [snip]
>> ... and that the naming issues on operator traits shall not be
>> a question of taste, whether someone likes them or dislikes
>> them temporarily, but a question of usability and cross
>> library simplicity that honors the choices made by others in
>> the past and acknowledges the fact, that those choices can not
>> be altered without breaking existing code.
>
> Well, since you restarted the discussion, I'll add a bit more
> myself in answer to your charges and conclusions.  I'm sure
> this comes as a surprise. :)

Hey Robert, I really didn't expect to meet you here in this thread ;)
Nice surprise though!

>> When I read your list of name choices I noticed that I got
>> pretty annoyed. And then I wondered why this issue upsets me
>> so much. I realized that I value the effort of maintaining
>> naming uniformity, consistency and simplicity *across*
>> libraries a lot and I think it is pretty unwise to sacrifice
>> that value for temporary and personal matters of taste.
>
> First, let's note that your concerns are matters of taste as well.

I don't like the names that the standard chose for the
operator-functors and that proto and other libs adopted either, which
are

plus, minus, multiplies, divides

and, if I could choose freely according to my personal preferences and
*taste*, today I would probably choose:

add, subtract, multiply, divide.

But my preference are different:
(1) Simplicity and uniqueness across standard and libraries which enhances
(2) Usability: Memorability. Ease of refactoring via textual
substitution. Perception of reoccurring patterns
(3) Honoring and respecting choices of other language and library
designers in the past.

So I defer personal taste in favor of the more valuable goal of inter
library naming consistency. And I did that. In my own library I had
chosen some names that I liked very much (taste) an I replaced them
which other names that I did not like so much, that were found in
other libraries and standards: (consistency goal).

> Your persistence that, for example, consistency with functor
> names in traits names is merely one of taste.  My taste differs,
> of course, on that point.

As everyone knows the functor objects in question are very thin
wrapper classes around operators that just call the wrapped operator.
It is completely reasonable to start from there using these names for
the operators in other contexts. IMO yours this a very weak argument.
You are stressing a tiny technical point, while I'd like to look at
the big picture.

> Let's also note that reasonable people can disagree on points of relative value and taste without getting carried away.

... your sidenote makes me wonder whether wise people would reply to
an open sharing in such a way.

And another argument. Given that one agrees on the goal of inter
library naming consistency, the choice of names is determined by the
prevailing names and can be chosen by an algorithm. So my approach is
also not a matter of taste here. The best, "most unifying" choices can
be computed and a measure of the consistency can also be computed.
Completely in absence of taste. This, by the way, makes the choices
extremely simple and easy to do, so one can concentrate on more
interesting work instead of loosing oneself in matters of taste.

>> Moreover I feel that important arguments and efforts pursuing
>> that goal have not been addressed in the discussion.
>
> Really?

Maybe you can help me finding the threads, where my main argument has
been addressed. And where it has been addressed by Frederic.

You did some remarks e.g.

2011/3/24 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> Joachim Faulhaber wrote:
>>
>> Comparing the names I tried to find "Most Unifying Proposals" for
>> names in column MUP:
>>
>> https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
>
> The summary table was helpful, Joachim.  Thanks.

Oh, thank you for that :)

> Names in the standard are certainly appropriate candidates for
> use in the Type Traits library, even if I would rather the standard's
> names were different.

And you also reiterated your argument of the big difference between
operators and operator-functors in order to argue that naming
consistency efforts were not applicable.

> Myriad arguments were raised on all sides of the issue
> *during* the discussion.

On my main argument of inter library naming consistency there were
only a few pretty weak ones. Maybe you can cite some more.

> With matters of taste, ultimately, there
> can be no right answer.

Yeah, and global naming consistency is not a matter of personal taste
but a matter of  transpersonal beauty,
(1) the beauty of simplicity and uniqueness
(2) the beauty of a large group of people agreeing in an evolutionary
process of convergence.

> I don't know what more Frédéric could have done.

Making a strong case against that and for his choices and why they
need to introduce divergence.

Cheers,
Joachim

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