[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lattice of kernel classes
- To: skeene@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: lattice of kernel classes
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 11 Apr 88 13:15 PDT
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>'s message of Mon, 11 Apr 88 15:14 EDT
- Sender: Bobrow.pa@Xerox.COM
1. In the diagram, there is a class named
"standard-structure". I think it is meant to be
"structure-object"; which is what it is called in the previous
section.
Right.
2. The classes <structure-object> and <standard-object> have
angle brackets around them, which indicates that they are used
primarily for type determination, like <class>, <method>, and so
on. I don't think of those two classes in that way; I think of
them as primarily being there to support default behavior of
instances of structure-class and standard-class. So, I would
recommend getting rid of the angle brackets.
I think that these classes serve both purposes. It is appropriate to test if an
object is structure using <structure-object>. So given the dual role of these
objects, do you think it better not to use <>, since that might indicate their
only purpose is for type checking, or is suffcient to amplify the statements
about their other roles in the text.
3. This section states that T is an instance of built-in
class, but the section "Instances of class, built-in-class, and
structure-class" states that an implementation can use
standard-class for ANY class associated with a Common Lisp type.
This seems contradictory.
The reason for making T be a built-in-class is to ensure that
a) no instances of T can be made
b) No direct subclasses of T can be made (without significant effort)
I think we need some way to ensure this. Either we have to make T an exception
to the rule in Chapter 1, or put this information in more directly in Chpater 3.