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

[Reimer Behrends]

Tim Peters (tim_one at email.msn.com) wrote:
> [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,

To the contrary; Eiffel, under no circumstances allows shadowing of
instance variables by formal parameters or by local variables. Yes,
changing stuff in a superclass can thus break code in a subclass; but
this can always happen (like if you add a new method that also exists in
a subclass). Doing a major internal change to a superclass requires at
least rechecking subclasses, anyway. (And I prefer compilers that are
too picky rather than too lenient.)

> 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).

Can you point me to the place in the Java language specification where
this is said? I'm asking, because I've heard that, too, but haven't ever
been able to find it and because the JDK happily allows to me shadow
instance variables left and right.

Of course, there are languages that don't have this problem. For
instance, in either Smalltalk or Eiffel, there are no modules outside
the class concept, and a variable is either local (which you can easily
see in the method declaration, or an attribute.

But I digress ...

[...]
> > 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.

Huh? Where have I said otherwise? I just happen to think that these two
goals are not mutually exclusive. And there should be a better solution
than the language ordaining a strange kind of Hungarian notation.

> 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.

I tell you what--I have this great idea for an addition to Python. You
know that you often can't tell what type a variable is? Well, we could
introduce the following convention:

	Require variables to be prefixed with "$" to denote scalar
	values--strings and integers, "@" for lists, and "%" for
	dictionaries.

Given the precedent of having to use self to access instance variables,
this is entirely consistent with the current language, and is going to
eliminate all those nasty problems where you can't tell from the context
what the type of a variable or function is. :)

	Tongue-firmly-in-cheek-ly yours, Reimer