Re: validate-xxx-class-change

[Gregor Kiczales <gregor@parc.xerox.com>]

   Date: 	Mon, 5 Nov 1990 20:56:05 PST
   From: 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)?  

I agree that it should be either (METAOBJECT CLASS) or (T CLASS).  I can
put the first in the MOP description; the second is for X3J13 to decide.

     (2) Why is it "ok" to change a metaobject into any other
         metaobject?

Right, I'll fix this.

   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".

If someone who knows how to program with the condition system will tell
me what works best, I will do it consistently with all these generic
functions.  My conern is for the quality of the error message signalled;
by having VALIDATE-XXX return true/false, I was hoping to make it easier
to do a good error message.