Re: New Class Organization for CLOS Kernel

[Danny Bobrow <Bobrow.pa@Xerox.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.

    Date: Mon, 28 Dec 87 15:51 EST From: David A. Moon
    <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    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.  

I agree with the principle stated below.  At first I disagreed with the
application of the principle to accessor methods based on Gregor's message, but
now I see it more as an open question.  Here are some issues I see. Can one use
an accessor to change (or fetch) the method-function of an accessor? Is the
contract of an accessor to be effectively just a call to slot-value?  Or can a
user insert a random function in an instance of type accessor method.  If the
issue of method-function is the only difference, then won't a specialized method
on method-function and (setf method-function) do the trick.  After all, these
accessors must combine in all the same ways that ordinary methods do, etc.
    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.
In thinking about this principle further I realized that we were missing from
the class lattice a type that allows us to distinguish objects whose metaclass
is structure-class.  I propose that we include a class structure-object disjoint
from standard-object, that is a guaranteed superclass of all objects whose
metaclass is structure-class. 

    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. 
I now believe that it would be fine to have :allocation be part of the
standard-slot-description class.  After our discussion in Cambridge, I think
that the value of a class slot is a joint association of the class and the slot,
not a property of the class-slot-description object.  This allows us to
eliminate the class standard-class-slot-description.

Missing from the specification is
  (class-slot-value class class-slot-name)
which returns the value associated with the class slot with name
<class-slot-name>.  It signals an error if class-slot-name does not specify a
class-slot (inherited or direct) at the given class. 
((Should this have gone in Chapter 2???))


    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.
In order to have a complete separation of the anonymous and named class
parts of the protocol, we need to convert names to classes before they
are stored as direct superclasses of a class.  One way to avoid having
forward-referenced-class would be to use an instance of standard-class
that did not have its direct-superclasses or direct-slots specified,
such as one created by:
   (make-instance 'standard-class)
Any attempt to use such a class in computing the class precedence list of a
subclass (a necessary prerequistite to making instances or defining methods)
would result in an error message of the form
  "Attempt to use a class with no direct-superclasses specified"
giving the class name if the class had one.  The advantage of using an
uninitialized standard-classes for a forward-referenced-class is that we need
this protection anyway.  A disadvantage is that we would need to provide (if we
do not specify direct-superclasses as a slot) a predicate 
  initialized-direct-superclasses-p (class) 
With instances of forward-referenced-class we could use a type test those
classes created by forward reference.  Programming environment tools may want
special methods on forward-referenced-class for display in browsers etc that
would be more difficult to write the other way.

If we have forward-referenced-class, I agree it should be disjoint from
standard-class. I am undecided which of these alternatives I like better.