[type_traits] Most Unifying Proposal for operator names Was: Review Typetraits Extension.
Dear Frédéric, Operatorists, list, on occasion of the current naming discussion on operator traits I started a wiki page with an operator functor naming table that allows for an overview over names of operators, functors (and related concept names) across the standard and boost. I compared the name stems only, independent of the question of a 'has_' or 'has_operator_' prefix. Basically it's an extension of Frédéric's operator names table 1.7 from his docs, extended by proto and boost::operator names. 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 Also I took a look at the current and new standard's functor class templates from header <functional>. I wonder why all the functors only use one template parameter, which restricts their use leaving out the interesting cases of functors for mixed type overloaded operators. template <class T> struct op_functor { ... } instead of template <class T, class U=T, class R=T> struct op_functor { ... } Also I don't understand, why inheritence form binary_function<T,U,R> is no longer declared, but instead of this, the redundant declaration of all associated types for every functor. Does this codereplication serve any purpose? Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
AMDG On 03/20/2011 01:00 AM, Joachim Faulhaber wrote:
Also I don't understand, why inheritence form binary_function<T,U,R> is no longer declared, but instead of this, the redundant declaration of all associated types for every functor. Does this codereplication serve any purpose?
Yeah. The standard only guarantees the typedefs, not inheritance from std::binary_function. The implementation is free to use std::binary_function, however. In Christ, Steven Watanabe
2011/3/20 Steven Watanabe <watanabesj@gmail.com>
AMDG
On 03/20/2011 01:00 AM, Joachim Faulhaber wrote:
Also I don't understand, why inheritence form binary_function<T,U,R> is no longer declared, but instead of this, the redundant declaration of all associated types for every functor. Does this codereplication serve any purpose?
Yeah. The standard only guarantees the typedefs, not inheritance from std::binary_function. The implementation is free to use std::binary_function, however.
Aha, this makes sense. Still I am wondering why functors are restricted to only one template type parameter. Extending the functors to 2 or 3 type parameters template<class T, class U=T, class R=T> struct plus; would make them much more useful while old code based on only one parameter should not be broken. Thanks, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
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. 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. I have some quibbles with your MUP choices, though. For example, you cite std::plus, minus, multiplies, and divides as naming examples from the standard, yet those are the names of function objects, not of operators. Given that Proto uses those names for the operators, there's some precedence for applying them in the traits, but I'd still prefer "addition," "subtraction," "multiplication," and "division" as the traits names. For brevity, and to more closely match the corresponding concept names, "add," "subtract," "multiply," and "divide" would be acceptable. Similarly, you used the function objects from the C++0x standard as the basis to justify "bit_and," "bit_or," and "bit_xor." Proto uses the better "bitwise_*" forms for the operators. Editorial comments: - For others just reading the table, putting "logical_not" with the other "logical_*" entries would be, well, logical - Similarly, putting pre- and post-increment and decrement together would be helpful - In the legend: s/MPU/MUP/ _____ Rob Stewart robert.stewart@sig.com 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.
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.
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.
[Non native speaker questions] Is this expression colloquial? Does it mean you wish the standard's names were different?
I have some quibbles with your MUP choices, though. For example, you cite std::plus, minus, multiplies, and divides as naming examples from the standard,
I was thinking about you, when I saw them, they're pretty inconsistent, aren't they?
yet those are the names of function objects, not of operators.
true
Given that Proto uses those names for the operators, there's some precedence for applying them in the traits, but I'd still prefer "addition," "subtraction," "multiplication," and "division"
ahh, a much more consistent naming :)
as the traits names. For brevity, and to more closely match the corresponding concept names, "add," "subtract," "multiply," and "divide" would be acceptable.
I agree these names are nicer as those chosen by the standard and proto ... Still (1) I would prefer uniformity over improvement here. I think it is of greater value, if we manage to converge names in boost and the standard, specifically in fields that are very fundamental to c++ as a language, which is clearly the case here. (2) If we considered to choose new names, I'd clearly prefer names that emphasize on syntax, to make clear that semantics is attached to operators by implementation sign semantics + cross addition, set union, concatenation, ... - dash subtraction, set difference, deletion ... * star multiplication, intersection, Cartesian product ... / slash division, factorization, ...
Similarly, you used the function objects from the C++0x standard as the basis to justify "bit_and," "bit_or," and "bit_xor." Proto uses the better "bitwise_*" forms for the operators.
Those three are a proposed addition to the new upcoming standard, all the others are in the current standard already. Maybe this mail http://www.mail-archive.com/boost@lists.boost.org/msg07394.html was the cause of their naming and appearance in the new standard. But from a wider perspective of maximizing naming consistency in boost and the standards, I think bitwise_* would be wise ;-) Also it'd be better to implement those functors completely (for all possible operators) and in their most general form e.g. template<class T, class U=T, class R=T> struct a_binary_op; // instead of template<class T>struct a_binary_op; which is in the current proposal.
Editorial comments:
- For others just reading the table, putting "logical_not" with the other "logical_*" entries would be, well, logical
In order to be "most helpful" I chose the sequence found in Frédéric's docs that seem to be odered by arity. In the long run I'd prefer to order according to precedences, which is probably the most useful ordering for users.
- Similarly, putting pre- and post-increment and decrement together would be helpful
- In the legend: s/MPU/MUP/ done.
If we can reach an agreement among boosters quickly we might be able to influence the standard now. Otherwise we'd have to wait for another decade :-/ Thanks Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Joachim Faulhaber wrote:
2011/3/24 Stewart, Robert <Robert.Stewart@sig.com>:
even if I would rather the standard's names were different.
[Non native speaker questions] Is this expression colloquial? Does it mean you wish the standard's names were different?
The use of "rather" versus "prefer" in that context is, probably, colloquial, perhaps even antiquated (I read a lot written by the likes of Dickens, Austen, etc.).
I have some quibbles with your MUP choices, though. For example, you cite std::plus, minus, multiplies, and divides as naming examples from the standard,
I was thinking about you, when I saw them, they're pretty inconsistent, aren't they?
yet those are the names of function objects, not of operators.
true
This is, in my mind, a significant point which you overlook below. [snip "addition," etc. and "add," etc.]
I agree these names are nicer as those chosen by the standard and proto ...
Still
(1) I would prefer uniformity over improvement here. I think it is of greater value, if we manage to converge names in boost and the standard, specifically in fields that are very fundamental to c++ as a language, which is clearly the case here.
It isn't uniformity when they name different things. Indeed, I consider using the same names for different things to be confusing.
(2) If we considered to choose new names, I'd clearly prefer names that emphasize on syntax, to make clear that semantics is attached to operators by implementation
sign semantics + cross addition, set union, concatenation, ... - dash subtraction, set difference, deletion ... * star multiplication, intersection, Cartesian product ... / slash division, factorization, ...
I'd never think of "cross" for "+". It has always been a "plus sign" to me. You also have the problem of "*" being "asterisk" and "-" being "hyphen" to different people. Besides, what would you call the corresponding concepts? IsDashable? IsStarable?
Similarly, you used the function objects from the C++0x standard as the basis to justify "bit_and," "bit_or," and "bit_xor." Proto uses the better "bitwise_*" forms for the operators.
Those three are a proposed addition to the new upcoming standard, all the others are in the current standard already.
It doesn't matter because, again, they are names for different things.
But from a wider perspective of maximizing naming consistency in boost and the standards, I think bitwise_* would be wise ;-)
Certainly, though conforming to names in the standard is wiser when they apply. That is, Boost should conform to the standard when reasonable.
Also it'd be better to implement those functors completely (for all possible operators) and in their most general form e.g.
Unrelated to naming the operators, I think.
If we can reach an agreement among boosters quickly we might be able to influence the standard now. Otherwise we'd have to wait for another decade :-/
One can always dream. _____ Rob Stewart robert.stewart@sig.com 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.
2011/3/24 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
2011/3/24 Stewart, Robert <Robert.Stewart@sig.com>:
I have some quibbles with your MUP choices, though. For example, you cite std::plus, minus, multiplies, and divides as naming examples from the standard,
I was thinking about you, when I saw them, they're pretty inconsistent, aren't they?
yet those are the names of function objects, not of operators.
true
This is, in my mind, a significant point which you overlook below.
[snip "addition," etc. and "add," etc.]
I agree these names are nicer as those chosen by the standard and proto ...
Still
(1) I would prefer uniformity over improvement here. I think it is of greater value, if we manage to converge names in boost and the standard, specifically in fields that are very fundamental to c++ as a language, which is clearly the case here.
It isn't uniformity when they name different things. Indeed, I consider using the same names for different things to be confusing.
Hmm, not extremely different though. The way the std functors are implemented is that they just call the operators without changing the semantics that is implemented for a given type parameter they are working on.
(2) If we considered to choose new names, I'd clearly prefer names that emphasize on syntax, to make clear that semantics is attached to operators by implementation
sign semantics + cross addition, set union, concatenation, ... - dash subtraction, set difference, deletion ... * star multiplication, intersection, Cartesian product ... / slash division, factorization, ...
I'd never think of "cross" for "+". It has always been a "plus sign" to me. You also have the problem of "*" being "asterisk" and "-" being "hyphen" to different people. Besides, what would you call the corresponding concepts? IsDashable? IsStarable?
Hmm different domains: Signs relate to the lexical/syntactic level, concepts to the semantic level... ... but I admit, some aspects of the lexical approach might be a little odd. Don't get me wrong. I like your naming proposals, but I'm still not convinced that the differences between the operators and their associated functors is so fundamental that it justifies to sacrifice a possible convergence of names. Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
participants (3)
-
Joachim Faulhaber -
Steven Watanabe -
Stewart, Robert