Subject: Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2011-05-03 02:11:51
On Sat, Apr 30, 2011 at 10:49 AM, Joachim Faulhaber
> 2011/4/29 Joachim Faulhaber <afojgo_at_[hidden]>:
>> 2011/4/29 Gottlob Frege <gottlobfrege_at_[hidden]>:
>>> On Thu, Apr 28, 2011 at 10:27 PM, Joseph Wu <josephclwu_at_[hidden]> wrote:
>>> I think (in order of strength of my opinion)
>>> - naming is very important
>>> - plus-equal (et al) is better than any of the other options
>> interesting ...
>> ... could you give us a deeper insight in the superiority of this
>> particular name?
Mostly I just wanted to voice my "vote". It is just my opinion.
But when I stop and think about my underlying reasoning, I think it
basically comes down to this:
In over 20 years of programming, across countries and continents, I've
never heard anyone call += "plus-assign".
I've always heard it called plus-equals.
I can get philosophical (and often do) and/or pedantic (again often
do), I thus I can understand reasoning about ambiguities,
consistencies, etc. But I think common language trumps all that, if
it is common enough. So maybe plus-assign is used elsewhere and I
just haven't heard it, but I know I hear plus-equals regularly. Also,
maybe it is important for standard or near-standard libraries to
strive for a higher, well, standard, and thus maybe it is our job to
use the "correct" terms. But I fear it just comes off too ivory
tower, instead of practical and pragmatic, in this case.
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), and I always think back to when I was a kid and we added
a room onto the back of our house (taking us from 800sq ft to 1000,
pretty small for a 3-child family, in Canada at least). Anyhow, we
always (and still) referred to the room as "the back room". Not "the
room at the back of the house" nor the den or family room or back
porch or... (because it wasn't exactly any of those things). "the
back room" was the shortest but still accurate / unambiguous /
This is how language (at least English, it seems) tends to work - we
instinctively find short names that work (or keep looking until we do
- which is why a lean towards "supports" or "can-call" or even "has",
and which is why this whole discussion exists, I think).
Now, interestingly, I notice that in everyday talk about = and ==,
there can be ambiguity, which is why, when reading code aloud,
everyone I've ever heard, says "x equals 10" when reading "x = 10",
yet when talking about overriding it, everyone calls it the
"assignment operator" since the "equals operator" might be ambiguous.
Which maybe is an argument on behalf of "assigns". I notice that "="
is not on the list at all - would it be called "supports_equals" in my
scheme? No, I would actually call it "supports_assignment". Yet I'd
still go with "supports_plus_equals" for +=. Is that inconsistent?
Maybe, but it is (in my world) consistent with common usage. Common
usage has decided to favour short words unless there is ambiguity.
And thus the scheme would be consistent (plus is plus is plus) except
where ambiguity dictates otherwise (equals becomes assignment only
when ambiguity forces it to).
Lastly, I often wonder if it comes down to brain
chemistry/behaviour/etc. Maybe other people are different, but when
I'm typing, I often hear the words in my head as I type it (of course
now that I'm conscious of it, typing becomes more difficult!). So I
find overly long function names or variable names are actually a
hindrance. Not just to typing, but to understanding. If I have to
think about "the room at the back of the house" instead of "the back
room" it actually affects my thinking. As a mathematician, I will
just replace a long term with X or an abbreviation (it seems we all
do). This isn't just for shorter typing - for me at least. It is for
more concise thinking - if a phrase can be turned into a single word,
it can be thought of as a thing of its own (a higher level object) and
no longer just a conglomeration of parts.
To me "plus-assign" or "plus-assignment" is a conglomeration of parts.
"plus-equals" has become a thing of its own, via years of usage. I
don't think of it as "add then assign back to x" I think of it as
"increase" or something like that. Maybe plus-assign would eventually
become the same thing, but we haven't called it that yet as
programmers, and unless we start doing so day to day (unlikely, given
the "rules" of language as I see them), we will still refer to it as
plus-equals, except for the special case of this boost library.
Or maybe it is just my opinion and gut reaction. Just one voice, one
"vote", hoping that it counts for something.
But since you asked (thanks for your interest - I do believe you are
looking for reasoning and being open to ideas, which is great), when I
stop and think about it, I *think* that's my reasoning behind my gut
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk