[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inheritance of Slots
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: Inheritance of Slots
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 10 Feb 87 13:27 PST
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Tue, 10 Feb 87 15:10 EST
- Sender: Bobrow.pa@Xerox.COM
I read the current document last night and was appalled
at the complexity of the rules that were used to explain the
inheritance of the characterisics of slot-descriptions.
Is this before or after Dick's venture at improving the way
it's described? The hardcopy I have (from Jan 31) doesn't look
extremely complicated, certainly less complicated than earlier
attempts. The English does need to be cleaned up a bit to make it
crystal clear, though.
Yes it is different in style completely. It makes a mathematical
statement of the inheritance rules. It is three times longer. I don't
think it changes the intent.
I think it's fundamentally complicated, because :initform,
:allocation, and :type have been specified by the group to work
three different ways, and changing any one of them to work the same
as another breaks something. My opinion is that the only way to
simplify it would be to get rid of some features.
I would be happy to get rid of :type at this point, and allow :type to
be added by the metaobject protocol using
I wouldn't mind it if one always had to (re)specify an initform if one
changed the allocation, and if allocation always defaulted to :instance
in any specification. This would mean that you couldn't add an accessor
to :dynamic or :class slots without repeating the :allocation. For
:class slots that would of course mean a slot in this class, as opposed
to having another way to access the one up above. To do the latter, one
could simply use defmethod.
I also realized that accessors and readers MUST be
inherited. A new method need not be built for every class if
the implementation guarantees that the method inherited still
works. But whenever there is a change of the :allocation
characteristic, every accessor and reader in the inheritance
chain must have a new method created for it.
I don't believe this is true. Could you specify some reasons
why new methods would have to be created? And do those reasons
mean that the following will not work?
(defclass c1 () (s))
(defclass c2 (c1) ((s :allocation :class :initform 1)))
(defmethod foo ((self c1)) (with-slots (self) (print s)))
(foo (make-instance 'c2))
How does this relate to the remark in the inheritance section
"Methods that access slots know only the name of the slot and the
type constraint ..."?
I am assuming (perhaps wrongly) that the methods to access a slot would
optimize the slot access and that access to an instance slot would be
optimized very differently than access to a class slot or dynamic slot.
If this is true, then all methods that have optimized slot access will
have to be redefined. If the underlying implementation can both
optimize and handle all three types of access, then I am wrong.