New Class Organization for CLOS Kernel

[Gregor.pa@Xerox.COM]

    Date: Mon, 28 Dec 87 15:51 EST
    From: 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.

I agree with this principle, but I don't see why
standard-accessor-method should be disjoint from standard-method.  It
seems to me that standard-accessor-method is a kind of method a lot like
standard-method.  It has qualifiers and specializers, it has a method
function.  It may also have some other information like slot-name or
other implementation specific stuff but all in all it seems a lot like
standard method.  It definitely seems to be a specialization of
standard-method. I guess my question is, given:

(defclass method () ..)
(defclass standard-method (method) ..)
(defclass standard-accessor-method (standard-method) ..)

What methods could you want to put on standard-method that you wouldn't
want standard-accessor-method to inherit.  It seems to me that for any
cases like that what you really want to do is make another subclass of
either standard-method or method and put your methods there.
 
			 
			 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.

That's the nature of it.
-------