[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Inheritance of Slot Options
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: Inheritance of Slot Options
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 5 Feb 87 00:05 EST
- In-reply-to: The message of 4 Feb 87 13:04 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Date: 04 Feb 87 1004 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
I think the current spec suffers from excessive rules for the sake
of marginal functionality. I propose this slight modification:
We break what was slot options into two categories, slot descriptions
and slot options (in the BNF, what was ``slot options'' becomes ``slot
descriptor''). Slot options are the :accessor and :reader guys. Slot
descriptions are :initform, :allocation, and :type. The slot options
are as before. Slot description inherit like this:
Let CPL be the class precedence list for C. If C's defclass doesn't have a
slot descrption for a slot it is totally inherited from the next most
specific class in the CPL. If C's defclass has a slot description, it
totally shadows any other in CPL. When this latter case happens, some of
the aspects of the slot description might be defaulted. The defaulting is
:initform is defaulted to unsupplied
:allocation is :instance
:type is T
The effective type of a slot is the AND of all types specified for it
in the CPL.
There are two differences between this and the previous rule (which I now,
unfortunately, understand). First, :initform acts differently - if you want
to change the :type or :allocation and keep the :initform, you have to mention
the :initform again. Second, it is an easier rule to understand and remember.
Third, when compiling a method you cannot assume anything about the types of
the slots, since a subclass could throw away your :type slot-option.
As far as I can tell this would make it impossible to use :type for anything,
certainly it seems to rule out the use you (Dick) mentioned for it when it
was first proposed.
I think it's counterproductive to have a complex set of rules to enforce
some intuition that doesn't pay its own way. A simpler but slightly inaccurate
model, where the inaccuracy to someone's intuition is unimportant, is
preferrable to a complex model that captures someone's epicycle.
These rules don't really seem any simpler to me. The concept of looking at
every slot-option in the class precedence list is no different from the concept
of looking at every method in the class precedence list; that concept has been
simplified out, but the concept of slot options and slot descriptions being
two different things has been added. No net gain.
In addition, I'm not happy about the idea that one cannot define an :accessor
for an inherited slot without clobbering its :initform. This seems just plain
wrong. It's a symptom either of your proposal not being right or of the whole
defclass syntax not being modularized properly.