Re: :allocation slot-option issues

[Danny Bobrow <Bobrow.pa@Xerox.COM>]

                          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.

I think it does apply to both class and instance variables.  The
variables seen by an instance (and this is the critical phrase) are just
those described in all the classes it inherits from.  (just as the
variables seen by an activiation are all of those in all scopes it
inherits from).  The instance sees only one varible of any name (as does
an activation).

 Some are stored locally, and some are shared (instance variables and
class variables vs local parameters and closure variables).   All
instances see exctly one description of any variable.  The most specific
description dominates (the one in the class nearest the front of the
class precedence list). Thus I am proposing that we have only one
:allocation option of this type :class.  Following is my proposal for
the inheritance.


Specification of Inheritance

None of :reader :accessor :allocation or :initialize-only (if we still
have that) are inherited.
:initform is inherited if not overridden
:type is inherited, but we do not specify what the system does with it.
An open question is whether inheritance here should be a union
operation, or if the more specific type must always be a subtype of the
inherited one.

:initform is evaluated as follows

1) Exactly once for :allocation  :instance at initialization time.
The value is stored in the instance.

2) At most once for :allocation  :dynamic, :class

  At first access for :dynamic and :class, unless first access is a
store.
The value of the initform is stored in the instance and class
respectively on this first access.

3) Each time for :allocation :none
   An error is signalled when trying to store in a variable with
allocation :none
The :none option is most useful at the top of a hierarchy where one
expects some subclasses to allocate storage, but on wants to write
methods that can assume they can fetch a standard value.  It can also be
used for subtractive inheritance at some significant cost.  



  danny