[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New Class Organization for CLOS Kernel



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

Principles:

1) We specify as disjoint the metaclasses that support built in classes,
structure classes and standard classes.

2) We provide classes in the lattice that support certain type determinations.
These type specifying classes will usually have no methods specified as
specialized to them in the kernel. (A possible exception is standard-object,
which is a guaranteed superclass of all instances that have standard-class as
their metaclass)

3)  We specify links only as subclass relations rather than direct subclass
relations, allowing implementations freedom to organize code sharing.

Result:

The following is a mapping of the class lattice.  Indentation is used to
indicate subclass relationships.  Class names surround by <..> indicate classes
used for type determination.  In general, these "taxonomic" classes are abstract
classes in the sense that they are not expected to be instantiated.

If the metaclass of a class is not standard-class, that metaclass is shown in
(...).

T (built-in-class)
  <standard-object>
     <generic-function>
        standard-generic-function (funcallable-standard-class)
     <method>
        standard-method 
           standard-accessor-method
              standard-reader-method
              standard-writer-method
     <slot-description>
        standard-slot-description
           standard-class-slot-description
        standard-structure-slot-description
     <class>
        standard-class
           forward-referenced-class
           funcallable-standard-class
        built-in-class
        structure-class
        

A link not shown in the diagram is the subclass link from generic-fucntion to
function.

     ----- End Forwarded Messages -----
  danny