[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: :allocation slot-option issues
- To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- Subject: Re: :allocation slot-option issues
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Sat, 3 Jan 87 20:47 EST
- In-reply-to: <861231-101817-1327@Xerox>
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
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
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
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.