total idiot question: +=, .=, etc...

[Tim Peters]

[Reimer Behrends]
> While I'd be the first to agree that C++ is not exactly the epitome of
> language design, I would think that at least the local variables should
> be easy to identify. The only real problem is to distinguish global
> variables from instance variables. And this is made worse in C++ by
> spreading all the information related to a class over more than one
> file. It should be noted that other languages do not necessarily have
> the same problem and that careful design can easily avoid it.

But even with declarations up the wazoo, distinguishing local from instance
vars is a major problem in real-life C++:  any OO language with declarations
has to allow local vars to shadow instance vars, else method implementations
can be broken by trivial changes in far-removed superclasses (e.g., Java
flatly prohibits shadowing in most cases -- but specifically allows this
one).

Any reasonably careful programmer will avoid such shadowing when the code is
first written, but under time & modification that never lasts; perhaps just
because the names most natural to a problem domain are limited.

So I've never worked on a (successful <0.9 wink>) C++ project where coding
conventions didn't require prefixing instance vars with some magical
sequence reserved for that purpose.  The one I'm working on now requires
member var names to match the case-sensitive regexp

    ^m[A-Z]\w*

and similarly starting with "g" for extern data and "s" for file-static data
(local names are "anything else").  Other projects enforced other
conventions -- it's a real relief to come back to Python and see it always
spelled "self."!

> But I do not think that the most basic operations of an OO language
> should be complicated by cumbersome syntax (this includes instance
> variable access and local method calls). The language should encourage
> use of these elements, not get in your way.

Readability is more important to me over the long haul.  Say what you like,
but which vars belong to the instance is screamingly obvious the instant you
see

    self.x = self.y + k

while in

    x = y + k

it's at best a minor puzzle and at worst a long & tedious grep project.

explicitly-favoring-explict-ly y'rs  - tim