[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: firstname.lastname@example.org
- Subject: Re: validate-xxx-class-change
- From: Gregor Kiczales <email@example.com>
- Date: Wed, 21 Nov 1990 22:37:40 PST
- Cc: MOP.PARC@xerox.com
- Fake-sender: firstname.lastname@example.org
- In-reply-to: "Jon L White's message of Mon, 5 Nov 1990 20:56:05 PST <9011060456.AA26438@caligula>"
Date: Mon, 5 Nov 1990 20:56:05 PST
From: Jon L White <email@example.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
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
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.