total idiot question: +=, .=, etc...
tim_one at email.msn.com
Fri Jun 25 03:12:38 EDT 1999
> 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
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
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
> 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
self.x = self.y + k
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
More information about the Python-list