[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: :allocation slot-option issues
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: :allocation slot-option issues
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 5 Jan 87 11:07 PST
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Sat, 3 Jan 87 20:47 EST
- Sender: 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
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
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
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
: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
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
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.