New Class Organization for CLOS Kernel

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 23 Dec 87 14:34 PST
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    The following is my understanding of what we agreed to in Cambridge.

Agreed, except for some problems with the class relationships:

standard-accessor-method and standard-method should be disjoint for the
same reason that standard-class, built-in-class, and structure-class are
now disjoint.  The principle underlying this is that we need to
distinguish between the class that is used by default by the various
macros, and the class from which other classes inherit.  This allows a
programmer defining a new method to choose whether this method is to be
applicable to the default kind of object that the macros make or to all
objects (of the relevant general kind).  For example, standard-class is
distinct from structure-class, and they both inherit from class, so that
a programmer can put a method on standard-class to affect classes made
by defclass, or on class to affect all classes.  Probably this principle
should be in your list of principles.

It's okay for standard-class-slot-description to be a subclass of
standard-slot-description, provided the idea is that
standard-class-slot-description is a kludge to avoid putting the
:allocation into a slot.  Otherwise there should be both
standard-class-slot-description and standard-instance-slot-description,
disjoint, and if we want we could also define a common superclass of
them.  I don't have an opinion on which of those alternatives is
right since I don't yet understand exactly what you're trying to do
with slot-descriptions.

Forward-referenced-class should be disjoint from standard-class for the
same reason, except that forward-referenced-class should not exist at
all, in my opinion.  It's okay for funcallable-standard-class to be a
subclass of standard-class if we really mean that
funcallable-standard-class is a specialization of the class you get with
defclass, not something distinct that wants to inherit some of the same
methods.  I haven't seen a written description of funcallable-standard-class
yet, but my understanding is that that is the nature of it.