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: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-04-21 09:36:47

Joachim Faulhaber wrote:
> 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
> [..]
> > +       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...
[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. :)

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

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

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

Really?  Myriad arguments were raised on all sides of the issue *during* the discussion.  With matters of taste, ultimately, there can be no right answer.  I don't know what more Frédéric could have done.

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

I think Frédéric followed both Boost style and good style.  He suggested names. He considered other suggestions.  He tried to find common ground.  He considered arguments and rationales.  He, as the library author, produced a final set in the hopes of finally putting the discussion to rest.

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

The reasons for the names were part of the discussion.  Do you mean that the names should be justified in the documentation?

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

There was no true consistency among the libraries.  First, this library queries capabilities, so it differs from many of the others in purpose.  Thus, naming differences are reasonable.  The same is true of Boost.Operator concept names: they differ from the other libraries because their purpose is different.  Second, there were some names that were inconsistent among the existing libraries.  That means some choices must be made and those are matters of taste.

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

Those names were selected because they name the operations, as commonly expressed, rather than worrying about grammatical consistency.

I know that I refer to the "addition operator," not the "plus operator" or "add operator," etc.  I know that some do use "plus operator," but that's a minority in my experience.  I certainly never refer to the "conjunction operator."  The names in the latest list look reasonable to me from that viewpoint.

> If you use "assignment" instead of assign, you should also use
> "equality" instead of "equal" and "negation" instead of
> "unary_minus" and so on.

Your argument for "equality" is sound, but then what are the names for <, >, etc.?  By contrast, I think "equal" is consistent with "less_than," etc.  It is common to refer to operator ==() as "operator equal," but I generally use "equality operator," so I'd be happy with using "equality."

The choice of "unary_minus" versus "negation" was for consistency with "unary_plus," of course, for which there doesn't appear to be a viable alternative.

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

You see problems where I see none.

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

If it was inconsistently applied, then reconsidering that approach was wise.  Furthermore, other arguments were made which were, apparently, compelling, if different from yours.

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

This is disingenuous.  During the naming discussion, it was plain that "has_" was disliked by a number of people because these traits were unlike the existing ones.  What's more, not every trait in Boost.TypeTraits begins with "has_."  "can_call_" seems the best choice among the suggested alternatives when applied across the full set of these new traits.  (Others worked better or worse, depending upon the trait to which they were attached.)

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

This is a straw man argument.  The names in the list are not widely divergent and are quite reasonable for many reasons.  Besides, I believe Eric was willing to consider modest alterations, suggesting he wasn't convinced that he had selected the best names.

[snip scenarios of libraries using different naming conventions]

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

Your proposal is based upon your own tastes.  I, for one, found fault with it as you well know.  Consequently, it can hardly be considered unambiguously better.

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

We certainly agree here.  However, you have different notions of where conformance is applicable and not.  "A foolish consistency is the hobgoblin of little minds" is a quote I try to keep in my mind in such discussions because I can get carried away with naming, etc.  In this case, I think creating a self-consistent set of traits is as important as one that kowtows to existing names.  If a trait were named in the standard, I would in no way suggest deviating from it.  However, the names of functors for operators do not require that traits determining whether the same operator can be called with specific types should be identical.  I see absolutely no reason to consider those names as precedent for the traits names.

> 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

According to your tastes, those might be the "most unifying names," but not to mine.

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

Surely that shows that Frédéric was appropriately influenced by the discussion, gained useful ideas, and created a new list that he likes better than those he created before.  Furthermore, his recent post indicated the list you should be studying now.  Why is that a problem?

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.