Boost logo

Boost :

Subject: Re: [boost] [Boost-users] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-03-30 13:00:26


Joachim Faulhaber wrote:
> 2011/3/30 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> > Joachim Faulhaber wrote:
>
> >> Standard and boost (proto, accumulator, phoenix, ...,
> >> boost::operator: "negatable") agree on "negate". Why
> >> celebrate diversity here?
> >
> > I agree with Frédéric. Consistency with "unary_plus" is beneficial.
>
> Where exactly is the benefit of creating a deviation from a naming
> that is already consistent across the standard and boost libraries?

Could you have expressed that question any more negatively? Why are you trying to be obtuse? The obvious answer is that if one discovers and uses "unary_plus," one would quite easily assume that the related trait is "unary_minus."

Furthermore, I don't agree that the standard uses "negate" for this purpose. Proto does, of course. That means I see no convention "consistent across the standard and boost libraries."

> > It would be possible to include both,
>
> For me uniformity is the major value here: Simplicity, uniqueness
> across libraries, ease of use for users.

Sure. I was just trying to suggest that it is possible to make both camps happy -- so long as they don't have to read one another's code.

> In my own library I renamed some functions after Barend told me that
> there are different identifiers for them in geometry standards,
> although I liked my function names better. I love name convergence. It
> allows us to perceive higher level patterns and fosters abstraction.
> Sometimes one has to let go from ones personal views, likes and
> dislikes to achieve this.

I agree easily with this result, given the weight of the industry terminology, but I contend that doesn't apply in this case. The only precedent I recognize in the "negate" case is Proto's name. It's the same reason I argue against "multiplies" and "divides." Those names are reasonable for function objects, but they are not the right names for the operators.

Clearly, you and I won't see this the same way, but the names aren't up to us. Frédéric will make a choice and we'll accept it whether or not it matches our own predilection.

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk