🚀 go-pugleaf

In article <1990Oct17.132314.26739@irisa.fr> boissier@irisa.fr (franck boissiere) writes:
>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
[paraphrased]
...case 2 all instances of the class or its subclasses share 1 variable
...case 1 of each distinct class or subclass share variables

My Suggestion:
Provide a way to share an initial value for the unshared variables.  If you 
want case 2, make the initial value a reference to the single shared storage.
If references don't work nicely, how about an Object ID?

I have (in a system with only type 1 class variables) used class variables 
to keep such things as instance counts and rings of instances of a class.
These things were mplemented in OBJECT, and inheritance propogated them
throughout the tree.  Even more important were some of the short-term 
hacks I put in for debugging which propogated counts of allocations and
deallocations and allowed me to chase memory leaks.  With my system (the
type 1 variables), I added in accounting code at allocate and delete times,
and could, at a function invokation, display lists of classes and counts
where the number of living instances had changed between calls.  Such code
is, admittedly, ``tricky'' code, but in an evening I had written it and
used it to chase memory leaks, and then removed it from the system the
following day (so the system kept its old memory efficiency).

I was language maintennance/implementor here, but I really suspect that
it is more common to want distinct variables per class.

-Scott Daniels		daniels@cse.ogi.edu