🚀 go-pugleaf

From article <1990Oct15.185718.8342@svc.portal.com>, by moose@svc.portal.com:
> In article <GREGOR.90Oct14231438@spade.parc.xerox.com> gregor@parc.xerox.com (Gregor Kiczales) writes:
>>With regard to the question about what kind of class variables people
>>want, here is a comment from another community.
>>
>>> 1 -- each subclass has its own copy of its parent's class variables
>>> 
>>> 2 -- all subclasses share a single copy of their parent's class variables
> 
> I think this arguement is beginning to get silly.  If you do #2, you can 
> always do #1 by adding a new variable and overridding all methods that affect
> the variable in question.  

Come on - "you can always do it by <some complex operation>" has no
weight whatsoever as an argument.  On that basis, I have seen people
argue that all the constructs you need for object-oriented programming
are the multiple subroutine entry points provided by FORTRAN II.

The need for using different values for a global variable in
subclasses is something that occurs rather often.  Example: If I want
to present ships on a screen, I want a specific picture (call it
"icon", if you will) for each class of ship (tankers, freighters,
etc.)

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.

> If you do #2, you can 
> always do #1 by adding a new variable and overridding all methods that affect
> the variable in question.

Which means either that

(1) I may access class variables in my programs only by way of by a
specific method.  Then I only have to change the method's code in a
subclass to get a new value.  In effect, I have then lost most of the
meaning of what is called a 'class variable'.  Besides, I can always
get the original value by using the variable directly.  This is rather
error-prone and somehow contradicts the idea of 'overriding.'

or that 

(2) every time I want a different value in a subclass, I have to
override (i.e., copy textually without changing the code) ALL methods
using that variable.  This may blow up the code (source and binary)
size of the system enormously and (a) is a good way to make the
relationship between super- and subclass quite confusing to somebody
who wants to understand the code - after all, there might just be some
difference in all those lots of methods which outwardly look the same,
and (b) when you change some methods (possibly in a way totally
unrelated to the variable that started the mess), you have to change
all the textually identical copies of these methods that exist in
subclasses.

Read Stroustrup's paper from the first ECOOP conference to find out
about the difference between "supporting" and "allowing" features.

> If you do #1, there is no way to do #2.  
> Therefore, #2 should be done.

It's easy to do #1 in a way that allows #2; #2 alone is a pain in many
situations.  Therefore, #1 is better.


Markus Stumptner                                mst@vexpert.dbai.tuwien.ac.at
Technical University of Vienna                  vexpert!mst@uunet.uu.net
Paniglg. 16, A-1040 Vienna, Austria             ...mcsun!vexpert!mst