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

Re: Class organization for CLOS kernel


   From: mcvax!delphi!chicca@uunet.UU.NET (M.R. Boscotrecase)
    Date: Thu, 21 Jan 88 13:00:36 +0100

   Hello! I work in the DELPHI team that is implementing CLOS on
    the ObjVlisp  model. In our architecture the class structure-class
    is an instance of the class structure-metaclass and inherits from
    the class built-in-class. The class  structure-metaclass is
    necessary in order to override the behavior of the class
    built-in-class (its make-instance method that produce an error
    message). What we have is the following

    (defclass structure-metaclass (class) () (:metaclass class))

    (defmethod make-instance ((class structure-metaclass) &rest
      initargs)  (...))

    (defclass structure-class (built-in-metaclass class t)
       (slotds conc-name constructors copier predicate include
         type named initial-offset documentation)) (:metaclass

    (defmethod initialize-instance ((class structure-class) ..)

    In the  mail I read that structure-class is instance
    of standard-class and I think this causes a bootstraping problem.
    Can you explain me why you  want it?

There are three disjoint metaclasses which represent the two old
ways of having structures in Common Lisp (built-in and structure) and
one for the new class structure.  These metaclasses themselves are all
instances of standard-class. Thus we have (approximately):
(defclass built-in-class (class) ())
(defclass structure-class (class) 
   (slotds conc-name constructors copier predicate include
    print-function type named initial-offset documentation))
(defclass standard-class (class)
   (direct-slots direct-superclasses direct-class-options))

The class named "class" is a "taxonomic" class that serves to identify
the common type of all these We also have two other "taxonomic"
classes, standard-object and structure-object, that serve as holders of
default methods for instances generated by standard-class and
structure-class respectively.  It is guaranteed by the system that any
instance of any class that is a standard-class has standard-object in
its class precedence list.  Any class that is an instance of
structure-class will have structure-object in its class precedence

The methods for making instances are:
(defmethod make-instance ((class built-in-class) &ret initargs)
   (error "can't make a builtin class this way"))

(defmethod make-instance ((class structure-class) &rest initargs)
    ;;; do what it takes to make structures
    ;;; call initialize-instance on the structure)

(defmethod make-instance ((class standard-class) &rest initargs)
    ;;; do what it takes to make standard instances
    ;;; call initialize-instance on the object)

(defmethod initialize-instance
  ((object standard-object) &rest initargs) ...)

(defmethod initialize-instance 
  ((object structure-object) &rest initargs) ...)

We do not see the need to have an extra level of metaclass
like your structure-metaclass. structure-class is not
a subclass of built-in-class. 
If we have
(defclass x-y-point ()(x y)
  (:metaclass structure-class))
then (make-instance 'x-y-point ...)
will invoke the method above on structure-class.  The class
of structure-class will not be involved.


The following is the most current version of the CLOS 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.  

T     (built-in-class)
        standard-generic-function (funcallable-standard-class)

A link not shown in the diagram is the subclass link from
generic-function to function.  We are also still discussing whether
standard-accessor-method should be a subclass of standard-method, or
only of method.