# Inheritance of Slots

• To: common-lisp-object-system@SAIL.STANFORD.EDU
• Subject: Inheritance of Slots
• From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
• Date: 06 Feb 87 2301 PST

Moon writes:

No, :allocation doesn't inherit.''

Moon wrote in CONCEPTS:

{\bf :allocation} comes from the most specific slot description in
the class precedence list---if it
does not explicitly specify {\bf :allocation}, the default is
{\bf :allocation} {\bf :instance}.''

What is the most specific slot description''? Is it the one closest
to the front? Is there some intrinsic specificity of a slot description?
What is it''? Is it'' the most specific slot description? Is it''
the class precedence list? Is this not some sort of inheritance?

Moon wrote in CONCEPTS:

{\bf :initform} comes from the most specific slot description
that explicitly specifies {\bf :initform}. ''

So what does this do:

(defclass c1 () ((s :allocation :class :initform 99)))
(defclass c2 (c1)((s :initform 22)))

Is S an :instance in instances of C2 ? Is it a :class in C2?  Is it shared
with the one in C1?  Do we reinitialize S?

{\bf :type} is constrained to satisfy all of the type constraints given
by classes in the class precedence list.''

What does constrained'' mean? Is there enforcement? Is it the same way that
slots in Defstructs have :type declarations? If so, this doesn't say it.
Steele's working is much better.

Well, maybe Moon's right, we should leave it as it is so that the readers of
the document can have fun guessing what this mess means. LGD and I sure had
fun for a day doing exactly this. All we were doing with our suggestions was
to propose something that someone could understand along with a description
of it that was understandable.

The point of a specification is to spell out the details in such a way
that they are precise, unambiguous, and clearly stated. This specification
does not do that.

-rpg-