On Wed, May 4, 2011 at 10:27 AM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
Your main point is the spontaneous and commonly observed "spoken" version of those operator signs. And it took me a little by surprise that this aspect has not been risen before (or has it? I'm loosing overview).
"Spoken-ness" is one point. Common usage is the other. Related points, but there are differences...
I think about the general problem of naming (of variables in code, etc) a lot (including Bertrand Russell's essays on "the King of Spain", etc),
sounds interesting, is the essay accessible via the web?
I had to do some googling: I'm pretty sure it was an essay called "On Denoting" (http://en.wikipedia.org/wiki/On_Denoting). Although I think when I read it, it was in a book, one chapter called "the definite article" and another called "the indefinite article", and I recall thinking it was pretty funny that someone could write so much about the word 'a' and so much about the word 'the' (and that I could find it so interesting). See also http://en.wikipedia.org/wiki/Theory_of_descriptions, http://evans-experientialism.freewebspace.com/frege_russel_is.htm, etc.
So, a lot of your very interesting point of view relates to "spoken" language and "spoken" c++ in particular (also inner speaking while typing).
... I can not compare my auditive experience to yours because my "spoken operatorish" is in German ;-) which is also pretty bizarre, because c++ spoken by Germans it is a wild mixture of German and English words and typically operators are spoken in German by German c++ narrators. This happens in a way as if, in the face of reading c++ operators the human brain degenerated to a lexical scanner that scans the tokens and translates them (using mother tongue) in those words sequentially that it has most frequently been drilled to use for the respective digits.
As stated on the outset, this operatorish narrator produces seemingly natural results e.g. UK plus-equals DE plus-gleich for += that seems to be "paralell natural" for the two languages,
but I have heard it producing cumbersome names like DE Prozent-gleich for %= or DE Doppelpunkt-gleich for := (not c of course)
because it seems not to "think" very much ;) Since no one ever says "modulus" for % in Germany, but everyone says "Prozent". Everyone would say DE Prozent-gleich for %= which would be 'percent-equals' in English.
I tend to call it - or at least speak it - percent-equals as well, although I might not want to use that as the name in this library - it could be confused with an operation that actually calculated percentages. Although, I guess since operators can be overloaded, in some sense the symbolic name "percent" is more accurate than how it operates on integers. x % y doesn't mean modulus for arbitrary classes. Maybe it does calculate percentages.
I see three Problems with your Spokenness Paradigm
(1) Spokenness of operators leads to non systematic sometimes awkward conglomeration of parts. (2) There are loads of differences of spoken operators in different languages. (3) Spokenness as a guideline is again not consistently used. Specifically not used consistently within column A We would, for example, need to name pre_increment as pre_plus_plus
Ah, but no one calls it pre-plus-plus. This is where spokenness and common usage diverge. We call it pre and post increment when we need to differentiate. If it was understood in context, I would explain to someone that "a list iterator overrides operator plus-plus to move to the next node in the list". But if I needed to give someone a task, I would probably be more precise - "you need to use pre-increment here, as it tends to be more efficient...". Etc. This, I think, is an important point. Possibly more important than "spokenness". I think we, for the most part, have already decided the names of these operators. By "we" I mean programmers at large. I mean common usage. Now maybe it is hard to measure common usage (maybe tallying google search results would help), but I think common usage has already decided it. (And yes, google says "plus equals" is 10x more common than alternatives) So it has already been determined via the genetic algorithms of programmers using terms and having some catching on and others not.
Moreover the rationals that govern the choice of names is very simple. See https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
That is a useful page. Obviously anything that aligns with the standard (current or C++0x) is pretty compelling. That leaves, I think: +=, -=,... plus_equal vs plus_assign <<... left_shift vs shift_left ++... pre_increment vs ... - unary_minus vs negate (std uses negate but std doesn't have anything for unary_plus) ~ and * are not in the standard, but I see no conflicting proposals there. And I'm NOT going to argue that symbols have no meaning (since the can be overloaded) such that ~ should be called 'tilde' and * should be called 'asterisk'. I'm not going to argue that. I'm fine with compliment and dereference. - is in the standard as 'negate', but I find the 'unary_plus' matches 'unary_minus' argument compelling. Of course, what would be even better would be to find a name for unary + that matches negate - ie 'posit' or 'positate' or something :-) Probably not going to happen. So I could live with either, or even both - ie include unary_minus and negate. But I personally prefer unary_minus. Not sure if I have a good argument for why. ++ pre_increment, prefix_increment, pre_inc,... is there any argument here? I suspect not. pre_increment works, I think. << left_shift vs shift_left. I find 'shift_left' to be the verb, and 'left_shift' to be the noun - ie the name of the operator. So I agree with left_shift. += I left this for last, hoping to have a good argument or good solution... I just don't like plus_assign. I see the idea of separating comparison from assignment. And the standard already set the standard for comparison, so I don't suggest changing it to equality or equivalence (nor do I suggest getting into the discussions about the possible different meanings of equality, equivalence, indentity, etc). The best I can do is suggest "equals" vs "equal" - ie note that the comparison operators use "equal" but multiplies, divides, etc, add an 's', and basically, I would say "plus-equals" not "plus-equal". Actually, I read "x += y" as "plus-equal" but I read "operator+=" as "operator plus-equals". I don't feel that is a great argument. So let me go back to common usage. Let's assume all the others (<<, ++, ~, *, etc) are decided, and only the += problem is left. If you gave the table to N programmers, with everything filled in except the += group, and asked them to fill in the blanks... no wait. Better yet, show them the rest of the table, then let them go write some code that requires type_traits::supports_+=, what will they automatically to type? I suspect plus_equals, or plus_equal or maybe even a plus_assignment, but 0 will assume that is is called supports_plus_assign or (has_plus_assign, etc). In this case I think common usage is more important than a slight ambiguity with equality. (You could even argue that plus_equals is *consistent* with equal_to, since they both use the same term for the same(ish) symbol :-) And/or feel free to argue that the standard should have used a term like "equality" or "omparable" or something. Basically the standard used common usage, I think, and to be consistent with that, we should too. (You could also argue that the standard's usage of common usage is an example of how it can later cause problems...) Lastly, I find these type_traits useful, so I will use whatever is decided, even if it is in German. But I appreciate the effort of finding good names. Actually, the last thing I wanted to mention (again) is that I really like "supports" over "has" or "can_call" or has_operator or etc. Tony