Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!tuvie!vexpert.dbai.tuwien.ac.at!mst From: mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner) Newsgroups: comp.lang.objective-c Subject: Re: Requirements for Class Variables for Objective-C Message-ID: <3713@vexpert.dbai.tuwien.ac.at> Date: 17 Oct 90 13:12:24 GMT References: <1990Oct15.185718.8342@svc.portal.com> Organization: DB and ES Subdivision, TU Vienna Lines: 74 From article <1990Oct15.185718.8342@svc.portal.com>, by moose@svc.portal.com: > In article 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 " 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