[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
:allocation :none
- To: Common-Lisp-Object-System@sail.stanford.edu
- Subject: :allocation :none
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 27 Jan 87 23:01 EST
- Cc: CLOS@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: <870126-143427-4458@Xerox>
Date: 26 Jan 87 14:33 PST
From: Ken kahn <kahn.pa@Xerox.COM>
I thought I should explain the original motivation for :allocation
:none. There are two expected uses of it.
1) A subclass implements an inherited slot procedurally (i.e. it defines
accessor methods) and doesn't need any storage set aside. :allocation
:none just saves some space in each instance but has no semantic import
(except maybe with respect to low-level slot access, i.e. slot-value).
2) A slot is not needed by a subclass. Declaring it :allocation :none
is both a cheap way to get an error if the instances really do need it
and again a way to save space in instances.
So I guess I'm agreeing with Moon that the slot continues to exist but
certain kinds of access to it are errors.
To some extent, the value of :allocation :none depends upon the style of
object-oriented programming. One style is to put alot of functionality
in the super-classes which sub-classes turn off. E.g. an
immovable-window is a subclass of ordinary window and needn't waste
space for slots used only in supporting movement.
In Flavors, we spent a lot of time some years ago discovering that that
style doesn't work very well. It worked out a lot better to split the
superclass into separate modules and then inherit whichever ones are
wanted. I haven't thought about it real deeply, but I think the Common
Lisp object system is similar enough to Flavors that it will work out
the same way.
If you believe this, maybe we should get rid of :allocation :none, since
it seems to make slot inheritance a lot harder to document and to
understand.