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