Re: :allocation slot-option issues

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 31 Dec 86 10:16 PST
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

        (1) The document currently says

           If the allocation type is :class, storage for the slot is
           allocated in the class object created by the defclass form.  The
           value of the slot is shared by all instances of the class.  Any
           subclass of this class will share this single slot unless the
           defclass form  for that subclass specifies a slot of the same
           name.  
        This is okay, but points up an inconsistency between
        instance-variables and class-variables.  Repeating the slot
        declaration of an instance variable does not create two separate
        slots, but repeating the slot declaration of a class variable does.
         I'm sure Alan Snyder would say that we should change instance
        variables to do the same as class variables, but I prefer to wonder
        if this indicates that something about class variables is broken.

    This is not the same as my model.  Repeating the slot declaration of a
    class variable does not create two separate slots accessible from any
    particular instance.  

That's true, given the qualifier "from any particular instance."

                          It creates a new one that overrides the one that
    would be inherited.  This is the same model as instance variables as far
    as I am concerned.

I don't see how you can say it's the same model.  With instance variables,
there is no overriding of a slot that would otherwise be inherited; there
is only one slot.  I suppose it must all be in how you look at it, but it
sure looks inconsistent to me.

    I like to think (talk about) the access scope of class and instance
    variables (whoops I should say slots): 
     1)  There is one variable by any name accessible from an instance.
     2)   It is the one nearest in scope.  If there is an instance variable
    by that name, then it is the one, else it is the one in the class of the
    instance or the most specific superclass of that class.   This is the
    same kind of nesting one gets in instantiation of function calls with
    lexical scoping.  If there is a local variable in the function, the
    local value in the activation is accessed, else the nested scopes
    containing the function definition are searched.  I think the analogy
    with inherited classes is very strong.  Another analogy is to think of
    classes as providing descriptions of sets, and subclasses describing
    instances of subsets.  Then the class variables are shared abong all
    instances of the set.

The analogy to lexical nesting for class variables is good, I found it
helpful.  It doesn't apply to instance variables, though, which is another
way of saying the same thing as my inconsistency complaint.

        Several months ago I remember we discussed splitting
        :allocation :class into :allocation :per-class and :allocation
        :shared (or some names like that) to address this problem. 
        :per-class slots get a new copy for each dependent subclass,
        whereas :shared slots are shared among all dependent subclasses,
        even if the slot declaration is repeated.  I think either the
        discussion was before this group got started or else it quickly
        dropped out of sight; I can't find it in any mail archives.  Can we
        open this issue and discuss the pros and cons of making this change?

    Neither of :per-class or :shared as you describe it has the semantics I
    mentioned.  Perhaps it would be useful to have an option
    :this-direct-class-only (meaning the class slot was accessible only to
    instances of this direct class), but I find that confusing with respect
    to the inheritance story.

:this-direct-class-only isn't the same as either of the ones I
mentioned, assuming that you meant to say that it doesn't inherit at
all.  :per-class is inherited, but creates a new slot each time it is
inherited.  :shared never creates a new slot, it always inherits the
same slot.  It's true that neither of these has the semantics you
mentioned.

So we actually have four options for class variables to consider.
I'll label them with the names that happen to have been used, with no
implication that I think these are the right names:

  :this-direct-class-only  --  never inherited

  :per-class  --  inheritance never shares

  :class  --  inheritance shares unless shadowed

  :shared  --  inheritance always shares

As I said at the beginning of this conversation, the current definition
is okay with me, but I think it's inconsistent and so I have to wonder
whether it's really okay; maybe it's only okay with me because I happen
not to have much interest in class variables.

Perhaps this issue should be combined with the one of defining precisely
the inheritance behavior of all the class options and slot options,
something we have never done.  I'd rather someone else be the leader on
that issue, since I already have plenty of work to do, but I'm willing to
make a proposal on it if no one else will.