🚀 go-pugleaf

In article <3713@vexpert.dbai.tuwien.ac.at> mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner) writes:
>The most natural way is certainly to treat class variables the way one
>treats methods: If I want to override it, I do, if not I use the
>inherited value.  [If you like, you can then consider methods as class
>variables containing function objects.]  I do not see why an approach
>that works perfectly well with methods should not also apply to class
>variables.  Both #1 and #2 can easily be united in this way.
>Unfortunately, that distinction is present in Smalltalk-80 and some
>other languages (perhaps for efficiency reasons?  I don't know) and
>some people seem to want to perpetuate it.

Take a look at the Self language, originally designed by David Ungar
and Randy Smith [OOPSLA '87].  It does treat variables just like
methods, and you can override a variable with another variable or even
with a method (and of course you can override a method with a
variable), and so would solve the class variable controversy exactly
as you describe.

Of course, treating a variable like a method has an adverse effect on
performance in simple compilers, and that's probably one reason why
most languages are not as flexible as Self in this regard (Trellis/Owl
is one notable exception, at least for instance variables; there's no
inheritance at the class level in Trellis/Owl).  But more
sophisticated compilers can eliminate this overhead, at least for
accessing instance and class variables of "self", by compiling a
distinct version of a method for each inheriting subclass.  See the
papers on the Self compiler for more details [e.g. OOPSLA '89, SIGPLAN '90].

-- Craig Chambers

P.S. Self doesn't have classes, instead using simple object
inheritance to model both class inheritance and instantiation.  But
languages with classes can still learn from the features pioneered in
classless languages, and adopt the good ones (like treating variables
as methods).