validate-xxx-class-change

[Jon L White <jonl@lucid.com>]

I can appreciate that one VALIDATE-CHANGE-CLASS is much better than
numerious VALIDATE-xxx-CLASS-CHANGE's.  But the several of the details 
of this proposal don't seem as well motivated to me.  For example:

  (1) Why is the checking method -- the :BEFORE method on CHANGE-CLASS --
      placed at the point (METAOBJECT T)  rather than at (T CLASS)?  First, 
      I say "CLASS" rather than "T" since it only makes sense for the second
      argument to CHANGE-CLASS to be a class.  But also I'm suggesting 
      extending this idea just like you said:  If this level of checking 
      is useful, then wouldn't it be suitable, and even desirable, for any 
      contemplated use of CHANGE-CLASS, and not just those that are moving 
      around methods, generic-functions, slot-definitions, and classes? 
      [For example, I might use this technique to permit the changing of an 
      instance (direct or derived!) of COLORLESS-TURTLE into an instance of 
      GREEN-TURTLE, but at the same time prohibit changing a RED-TURTLE into 
      a GREEN-TURTLE.]

  (2) Why is it "ok" to change a metaobject into any other metaobject?
      Your sample code has:

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

      Can you really change a standard-accessor-method object into a 
      slot-definition object with impunity?  I should think that the 
      proposal would take the opposite tack of generally denying the 
      ability to make such changes unless there is an explicit enabling 
      method on VALIDATE-CHANGE-CLASS.  The model I have in mind is more 
      like VALIDATE-SUPERCLASS.  [This also re-raises the question of 
      what are the metaclasses for the various metaobject classes, since
      the absence of a method on CHANGE-CLASS is a kind of restriction.
      The only prescribed method on CHANGE-CLASS is for changing one 
      STANDARD-OBJECT into another -- i.e., you can change the class of 
      any standard object as long as you stay within the STANDARD-CLASS 
      fold --  but there are no presrciptions for changing, say, a 
      funcallable instance into a STRUCTURE-OBJECT.  In particular, I 
      have already asked that GENERIC-FUNCTION and it's descendents not 
      be required to be standard classes; and I think I would like to 
      ask that METHOD-COMBINATION also not be so required.] 



Now, regarding some more specific points.


re: If VALIDATE-CHANGE-CLASS returns, the class change proceeds.

I dislike the assymetry of action with VALIDATE-SUPERCLASS, and prefer
the latter's semantics.  Your :BEFORE method on (METAOBJECT T) could
just as easily be defined to signal an error unless VALIDATE-CHANGE-CLASS
returns "true".


re: . . . suppose the user defines two class metaobject classes,
    MY-FAST-CLASS and MY-SLOW-CLASS. 

What's the difference between a "meta" class and a "class metaobject" class?
[I was able to follow the remaining discussion only because of the common 
tradition of nameing metaclasses as <foo>-CLASS whereas vanilla classes are 
usually named like <foo> or <foo>-OBJECT.]




-- JonL --