[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: validate-xxx-class-change
- From: Jon L White <firstname.lastname@example.org>
- Date: Mon, 5 Nov 1990 20:56:05 PST
- Cc: MOP.PARC@xerox.com
- In-reply-to: "Gregor Kiczales's message of Sun, 4 Nov 1990 13:56:42 PST <90Nov4.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)? 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
(2) Why is it "ok" to change a metaobject into any other metaobject?
Your sample code has:
(defmethod validate-change-class ((object 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
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 --