🚀 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:
>>
>>> 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