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 13:29:51

Joachim Faulhaber wrote:
> 2011/4/21 Stewart, Robert <Robert.Stewart_at_[hidden]>:
>
> 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).

You adopted standardized names for the same or similar behavior in your library.  That's a good thing.

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

OK

> It is completely reasonable to start from there using these
> names for the operators in other contexts. IMO yours this a
> very weak argument.

I consider your argument that they apply weak.  Where does that leave us?  It's subjective.

> You are stressing a tiny technical point, while I'd like to
> look at the big picture.

I'm stressing that the purpose of the functors is to encapsulate the operation.  The purpose of the traits is to determine whether the operation is applicable in a particular context.  Since they do different things, have different semantic purposes, they don't need the same names.

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

I was referring to the length of your post, and its repetitiveness, but also hoping to preclude much further wrangling.

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

Whether a name should be considered as a precedent can be subjective.  Once admitted as applicable, a name should be used to influence future choices.  I don't consider the standard functor names or the concept names in Boost.Operators as applicable.

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

I really don't have the time, but my recollection is that everything was discussed at length.  I can't, however, control whether you feel that was the case.

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

You seem to be labeling any counterargument as weak.  I think I covered the issues against your MUP more than once now and pretty thoroughly, and that includes discussion of the consistency among the libraries.

> 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'm still waiting for that large group to weigh in.  We've had some others participate previously, but I suggest letting this ride and get more opinions on the new list.  OTOH, if no others weigh in, then Frédéric's choices win, since he's the author (unless John Maddock chooses to intervene).

In the meantime, try this exercise.  Pretend you've forgotten the traits names (or, because there have been so many, you can't remember any now)!  Suppose you're writing code and need to determine whether t @ u can be called, for some operator "@."  What is the trait name for that operator, given that you remember it starts with "can_call_," of course?

For example, what name do you think of to determine whether t + u is callable?  Do you think of "plus," "add," "addition," "addable," or something else?  I think of "addition."  How about t * u?  Is it "multiplication," "multiply," "multiplies," "times," "star," or something else?  I think of "multiplication."

Do that honestly for each operator and see whether the names in the latest list are what you think of first or close to it.  I find Frédéric's latest list about perfect on that score.  If there's consensus that the names are very close to ideal when considered this way, then we'll find that those names will make using the library about as good can be.

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

I'll leave that for him, then, with the caveat that I see much less divergence than you.

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