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


I propose to replace all the validate-xxx-class-change generic functions
with the following, simpler facility.  I believe it is just as powerful,
and conceptually easier to understand.  It may even be that people will
want to extend it to cover change-class in general.

(It would be even simpler if CLOS were Self, but its a bit too late for
that now!)

This adds a before method to CHANGE-CLASS, specialized to (METAOBJECT T)
which calls VALIDATE-CHANGE-CLASS on the object and the prototype of the
new class.  If VALIDATE-CHANGE-CLASS returns, the class change proceeds.
A specified method on VALIDATE-CHANGE-CLASS, specialized to (METAOBJECT
METAOBJECT), always returns.

Here is the naive implementation model code:

(defmethod change-class :before ((object metaobject) new-class &key)
  (validate-change-class object (class-prototype new-class)))

(defmethod validate-change-class ((object metaobject) (prototype metaobject))

A user program which wants to prevent a metaobject from changing its
class defines appropriate methods on VALIDATE-CHANGE-CLASS.  For
example, suppose the user defines two class metaobject classes,
MY-FAST-CLASS and MY-SLOW-CLASS.  The idea is that the fast class
compiles in a bunch of stuff in an irrevocable way.  A fast class has to
stay that way, it can't have its class changed.  Also, the only way to
make a fast class is to create it that way in the first place, you can't
change something into a fast class.  The following two methods would

(defmethod validate-change-class ((o my-fast-class) (n t))
  (error "Can't change ~S away from being a fast class." o))

(defmethod validate-change-class ((o t) (n my-fast-class))
  (error "Can't change something into a fast class.  The only way to~%~
          to make a fast class is to create it that way in the first