knut-skog%rglab.uit.uninett@NORUNIX.BITNET (Knut Skog) (03/07/89)
After a close inspection of the elegant implementation
of classes and message-pasing by the rutines in class.ps
I am unable to see the reason for the distinction made
between instance- and class-vars in the definition of
the LiteWindow class .
I would have put several of the class vars (f.i. FrameLabel,
PaintClient, etc) as instance vars. In effect that is what
happens when a { /FrameLabel (<somelabel>) def} is sent
to some window instance. The definition is added to the
instance and since the instance is currentdict when the message
is executed, this definition overrules definitions in its parent class
as long as the keys are the same. (Using store insted of def
would be rather bad style of programming)
Installing attributes of this type as class-vars reduces
generality.
Despite the "lite/play" nature of this class I wonder if someone
close to its design will comment on this issue. Have I missed
out some esential part of the nature of instance and class properties?
Much obliged.
Knutknut-skog%rglab.uit.uninett@NORUNIX.BITNET (Knut Skog) (03/14/89)
Thanks to Cris (cws) and Greg @Sun for instructive comments. Gregs comment: > Now, LiteWindow has not made all the right > choices (by a long mark), so some of them can not be explained. removes my first source of confusion. Yes, I too thought that instance-vars was non-shared and class-vars was shared by all instances, however Chris' comment on composit objects as instance vars gave me a new understanding of the term non-shared. Is it right to state that class vars are shared and so is instance vars that are composite (string, array, dict, proc). Only the instance-vars that are simple objects are non-shared. To me this looks like a small problem. In object oriented system design a class should be constructed based on the true nature of the attributes of the objects under consideration. Class variations should be taken care of by subclassing and truly private data of a class instance should be defined as instance vars. The fact that class-vars is 'turned into instance vars' (placed in Instance dict) as soon as their attributs are assigned dynamicaly and therby makes it preferable to write 'natural instance attributes' as class-vars, is a pecullarity of this system that class-writers must be aware of. Right? In my 25-years as computer professional I have never had a more enjoyable and interesting experiance than NeWS. krg, Knut Skog Comp SC. Dep Univ. of Tromsoe, Norway
sjs@spectral.ctt.bellcore.com (Stan Switzer) (03/14/89)
In article <101*knut-skog@rglab.uit.uninett> knut-skog%rglab.uit.uninett@NORUNIX.BITNET (Knut Skog) writes: > .... In object oriented system design > a class should be constructed based on the true nature of the attributes > of the objects under consideration. Class variations should be taken care > of by subclassing and truly private data of a class instance should be > defined as instance vars. The fact that class-vars is 'turned into > instance vars' (placed in Instance dict) as soon as their attributs are > assigned dynamicaly and therby makes it preferable to write 'natural > instance attributes' as class-vars, is a pecullarity of this system that > class-writers must be aware of. Right? This is indeed true (so long as you use "def" and not "store" to change the values). It is an interesting and useful feature of NeWS's class system that default values for instance variables can simply be declared as class variables. Generally, with variables that reflect user preferences, etc., and which don't change too much (i.e. aren't *really* part of the object's dynamic state) I make them class variables with the understanding that they can be overridden by assigning to the instance. Additionally, such variables can be overridden in subclasses. Although this feature is somewhat unusual it is not unique to NeWS. The language "Self" described in the '87 (I think) OOPSLA has the same property. In a "true" object-oriented system, ALL data would be objects. In this case, the distinction between shared and non-shared object usually remains. Generally, composite objects are shared and simple objects (in SmallTalk, just the small ints) are not. (The point is somewhat moot since there are no operations that *change* atomic objects, only operations that create new immutable objects, so you really wouldn't know if they were shared or not.) In any system with class variables (or other means of namespace sharing) one must distinguish between shared objects and shared references to objects. > > In my 25-years as computer professional I have never had a more > enjoyable and interesting experiance than NeWS. Likewise. I haven't had as much enjoyment programming since I first got my hands on LISP 1.5. In the elegance of its conception and the virtuosity of its execution NeWS is nearly unparalleled. Stan Switzer sjs@ctt.bellcore.com "NeWS -- The windowing system for the other half of your brain." -- Don Hopkins