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 05:54:11

Hi Frédéric,

2011/4/20 Frédéric Bron <frederic.bron_at_[hidden]>:
> I have updated the type traits extension for operators:
> - new names beginning with can_call_
> - simpler names for helper traits
> - fixed typos in documentation
> - dont_care as default return type; check for exact void return when Ret=void
> - names of template parameters now begin with a capital letter
> followed by lower case letters (RHS->Rhs, LHS->Lhs, RET->Ret...)
[..]
> It is not finished; more to come...
>
> Frédéric
>
[..]
> +       can_call_addition
> -       can_call_subtraction
> *       can_call_multiplication
> /       can_call_division
[..]
> +=      can_call_addition_assignment
[..]
>
> PS: Please, find below the list of chosen names. I would appreciate
> not to start again a discussion about the good/bad of this choice.

I am sorry that I don't live up to your expectations here, but I think
that you did not complete the discussion about the rationals of good
naming for those names and that I did not see you addressing arguments
that I raised, specifically those that prefer inter library
consistency over personal taste...

> I am sure there are at least 2 persons that like it, sorry if not
> more...

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

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.

Moreover I feel that important arguments and efforts pursuing that
goal have not been addressed in the discussion. I don't think it is
boost style or good style in general to end an open discussion like
this by declaration of a final list.

Your list of final namings (in this thread) introduces a number of
names that are neither used for the analogous identifiers in the
standard nor in Boost.Proto or other boost libraries. I see you
deliberately introducing a diversification of names without giving a
justification.

(1) I think that this ignores my main argument that cross library
naming consistency is more important than local taste considerations.

(2) I also think that you ignore choices of other language and library
designers that have been made in the past, including the choice to
value consistency over personal taste. Implied in ignoring those
choices is the attitude that their choices from the past are inferior
to your current choices.

(3) I feel that efforts made to support cross library naming
consistency by e.g. setting up the wiki page are ignored and unused.

(4) The new choices are inconsistent to the standard and prevailing
boost libraries and are in addition inconsistent in themselves:

(4.1) I see you using prefer the grammatical form of substantives now.
Hmm, ok. So addition for plus, assignment for assign etc. If you
choose "addition" instead of "plus", you should consistently also use
"conjunction" instad of "and", "disjunction" instead of "or". If you
use "assignment" instead of assign, you should also use "equality"
instead of "equal" and "negation" instead of "unary_minus" and so on.

(4.2) Instead of reducing diversity and enhancing cross library naming
consistency you seem to introduce new problems.

(5) I think the rationals and rules you are working with for naming
choices are in themselves inconsistent and changing.

(5.1) In the last version of your docs you justified your name choices
referring to choices made in the standard (although not following this
rule consistently), which I strongly second. Now your seem to abandon
this maxim completely.

(5.2) In the review version of you library extension, you chose the
has_ prefix in order to be consistent with you parent library that
uses the same prefix for many of its traits. Now you are introducing
inconsistency against your parent library using a novel prefix
can_call_.

(6) If we consistently chose to the best of our current knowledge
names and ignoring prevailing names, what would happen. Suppose we had
a bunch boost authors each of them working on a library that has some
names refering to operators.

(6.1) Author A finds substantives unfortunate and feels the rule that
a name associated to a operator should be completable to its concept
name and she thinks that prefix has_ is nice because Boost.Typetraits
uses is already:
She chooses has_add, has_subtract, has_multiply, has_divide,...
instead of can_call_addition, can_call_subtraction, ...

(6.2) For a different library referring to operators in some way
author B considers, that operators can be implemented for different
semantics. Therefore he chooses for extremely good reasons general
names. He loves his names to be auto sorted by those general names
first, so he chooses a suffix:
for + : combine_is_applicable,  - : uncombine_is_applicable, * :
product_is_applicable, / quotient_is_applicable

(6.3) Author C has the insight, that authors before her were ignorant
of the fact, that any specific or general name suffers from that fact
that implementing a special semantics for the operator may lead to a
wrong meaning anyway. So deliberately she chooses names that refer to
the syntactic nature of the op sign:
For +: has_plus, -: has_minus, *: has_asterisk. /: has_slash, ^ : has_caret etc.

(6.4) Author D loves Haskell and short concise naming. He decides that
the applicability of an operator is nicest expressed by the third form
of a verb like "adds" which means that addition can be called on some
matching signature of types. So he chooses:
For +: adds, -: subtracts, *: multiplies, /: divides

(6.5) Author E ... etc.

(6.5) Every Author X is deeply convinced of their points of view and
finds some support in discussions on the list, so they decide, that
their personal superior choice of naming is indispensable. So each of
them implements their own superior naming in their library ignoring
their fellow authors and the namings that have been chosen in the
past. They might regret a little that very similar things are now
expressed more and more diverse in the lands of c++ and boost and that
users might constantly stumble over problems related to that naming
chaos.

(7) Behavior described in (6) not only is malicious, because it leads
to naming chaos where users not only are hampered but also disgusted.
It also leads to hodgepodge of different rules and rationals. In
contrast to that a rule that aims to maintain inter library naming
consistency is very simple (See my concrete proposal here
https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators).

I'd like to propose a meta rule

A naming consistency L that is local, temporary and specific has to be
sacrificed for
a naming consistency G that is global, durable and general, even if G
contains partial inconsistencies from a current point of view.

Local: Single library
Global: Cross library and/or language stadard

Temporal: New library
Durable: Existing libraries are affected.

Specific: A current discussion. Specific point of view
General: A general process relating to many libraries

Finally as I have done before I'd like to stress that this is not a
small thing. Since operators are at the core of the language, I expect
that your operator type traits will be used by thousands of developers
for years and decades. Naming inconsistencies will make it more
difficult for them to memoize, use and manipulate operator traits in
their programs.

This means that in choosing names you have a responsibility not only
to serve your taste but to serve the users. Inconsistency is very
easily created but it is impossible to get rid of it, once your
extension is in the boost release and people start writing programs.

So my request is this: Please use those names that are the *most
unifying names* with respect to the language standard and the existing
boost libraries. These names or name components are contained in the
MUP column of the wiki page:
https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators

... and please don't confuse me further ;-) As I just looked to the
wiki page I fould that meanwhile there are *3* different versions of
*your* proposals for your names!

(1) The list in this thread. Flavor "substantives"
(2) The list edited by you in the wiki page. Columns proposed new names and
(3) a new table with different names yet again.

I hope you'll get my point. Please don't take it too personal, if I
appear a little harsh. It's because I think inter library consistency
really matters a lot.

Confused and frustrated ....

Joachim

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