[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