Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!mcsun!inria!irisa!boissier From: boissier@irisa.fr (franck boissiere) Newsgroups: comp.lang.objective-c Subject: Re: Requirements for Class Variables for Objective-C Message-ID: <1990Oct17.132314.26739@irisa.fr> Date: 17 Oct 90 13:23:14 GMT References: <1990Oct15.185718.8342@svc.portal.com> Sender: news@irisa.fr Organization: IRISA, Rennes (FR) Lines: 54 From article <1990Oct15.185718.8342@svc.portal.com>, by moose@svc.portal.com: > In article gregor@parc.xerox.com (Gregor Kiczales) writes: >> >>> 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. If you do #1, there is no way to do #2. > Therefore, #2 should be done. > -- I think there should be a clear distinction between 1 and 2. Just take a look at what they can be used for: With case 2 all instances and "subinstances" (instances of subsequent subclasses) will be able to share a common variable which can be a common setting or a default value for some attribute (default size for example). This advocates for the so called class variables, accessible from the class and instances methods. With case 1 you can store values which can be shared throughout the class scope but are not relevant to subclasses. One example: suppose you have a class named cursor which is a subclass of a Bitmap class with a new attribute for the "hot spot". You may think of defining the default bitmap as a 16x16 White bitmap, name it default, and be able to have with the same name a default cursor which can be something else, but more important, as a cursor it NEEDS a hot spot. Another case which I use quite often is to have a hierarchy of object which can be displayed graphical with "standard" representation yet specific to each of the object classes. You can do it efficiently with case 1 defining a glyph class variable, and initialize it differently for each class in the subhierarchy. This is what can be called class instance variables, a common name but with a different specificity at each level of the hierarchy. Of course if you don't have 1 and 2 you can always redesign the implementation and tweak it to be able to solve my examples, but there will always be some cases not solved. As a summary 2 is clearly needed, 1 might be very usefull and powerful even if it is difficult do understand its power at a first glance. A good environment should provide 2, to be outstanding you need 1. -- Franck BOISSIERE boissier@irisa.irisa.fr Prototyping Lab Manager boissier@ccettix.UUCP C.C.E.T.T. B.P. 59 boissier%irisa.irisa.fr@uunet.uu.net 35512 CESSON SEVIGNE CEDEX FRANCE