I've never seen any confusion on the matter, but I take your
word for it, and rethink the terminology.
Most of the time, there is no real confusion. Human languages
contain a lot of redundance, and context helps. (In practice,
too, most of the people who use the word "method" are OO freaks,
and don't have any non-member functions
.)
Of course they do. To me, a "command" is an object
representing a user request, and "query" is a specification of
information to be obtained from a relational database. I'm
pretty sure "method" is more widely understood than "command"
or "query."
I didn't say that they were perfect. Just better than "method".
It's true that if I hear the word "query", I think data base,
and if I hear the word "command", I think of something entered
at the command line. But neither word comes up otherwise in C++
(or Eiffel, or whatever compiled programming language I'm
using). Where as I use different methods to develop C++ code
all the time. It's all a question of how much the context might
overlap.
So do "const" and "non-const."
With regards to clarity, the "official" C++ terminology is
pretty close to perfect for C++ (where there is no distinction
between functions and procedures, or whatever you want to call
them). With regards to verbosity, "non-const non-virtual member
function" isn't the shortest thing around
. But most of the
time, context will allow dropping some of the adjectives, with
no loss of understanding.
And I wouldn't use "command" and "query" in a C++ community,
because no one would understand what I was talking about.
Similarly, I don't normally complain if someone uses method, as
long as the context makes it clear. Because people understand
the term---whether it was well chosen to begin with or not.
[...]
I had also heard that functions mapped data from one space to
another (i.e. returned values), whereas procedures did not.
That's more or less the "theory" I was thinking about. The
"mathematical" definition.
The only prohibition I've ever heard on side effects, outside
of functional programming is for "predicates." I am firmly of
the opinion that if something has side effects, it should not
be called a predicate.
When I said "in theory", I thought it would be understood: in an
ideal world. I'm well aware that practical considerations
intervene. (And the reason you hear more about the prohibition
on side effects in functional programming is that functional
programmers tend to be more concerned with theory than C++
programmers, who are, judging from those I know, generally
pragmatists.)
I don't know that "just" depending on side effects is any less
clear than assignment.
One rule that I've found useful for ensuring clarity is that a
statement does one, and only one thing. Statements that modify
10 or 15 different variables, or that modify a lot of variables
while also controlling flow, make programs harder to understand.
So having an assignment statement, and a procedure call
statement, makes some sense.
But again, it's a general rule, not something absolute. IMHO, C
goes too far in one direction, Pascal too far in the other, but
on the whole, I'd favor something closer to Pascal than to C.
In particular, given a vector v, v.insert(3) seems much
clearer to me than (say) v += 3 (the string style) or v << 3
(the Qt list style).
I'm totally in agreement there. But v.insert() doesn't have to
be a function (in the Pascal sense); it could be a procedure.
Where the discussion becomes interesting (because there is no
one right answer) is when one introduces the possibilities of
chaining, or something like v.erase( iter ), which returns a
valid iterator so you can continue iterating. The Pascal rule
that you can't ignore a return value doesn't work well with
these sort of functions.
Similarly, I'm fine with assignment statements that have no
immediate side-effects, e.g. those used in expression
templates.
Well, they do have side effects in the compiler (and of course,
they're always constant expressions fully evaluated by the
compiler).
The important point here, however, is that the idioms we use
have grown up within the language, based on the language. Had
the language been different, we'd have developed different
idioms. In the end, you always end up with a complex total
which is more than just the sum of its parts. I find
discussions about "what if" some aspect of the language were
different interesting, abstractly, but in practice, of course,
you can't just change one part and expect everything else to
remain the same, and you can't really know what the effect would
be on everything else.
