[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
change to instance structure protocol
- To: Moon@stony-brook.scrc.symbolics.com
- Subject: change to instance structure protocol
- From: Jon L White <email@example.com>
- Date: Fri, 30 Nov 1990 14:09:38 PST
- Cc: firstname.lastname@example.org, MOP.PARC@xerox.com
- Comments: spoke too soon, but by how much?
- In-reply-to: "David A. Moon's message of Thu, 29 Nov 1990 21:57-0500 <19901130025720.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>"
re: >From p.13 of the July 30, 1990 metaobject protocol specification draft:
"Any method, defined by a portable program on a specified generic
function, must have at least one specializer which is not a specified
So "the standard metaclass" implies "no user-defined methods" (except
for the bug with EQL specialized methods that Cyphers pointed out, which
I imagine is one of the banes of Gregor's existence too).
(defclass moons-loophole () (some-slot))
(defmethod slot-value-using-class ((meta standard-class)
However, I'm still in the dark as to what you mean by "the standard
metaclass"? Are you simply referring to STANDARD-CLASS, or to
STANDARD-CLASS and all possible subclasses thereof (whose methods
for SLOT-VALUE-USING-CLASS might inherit, override, or extend the
Now, regarding the quoted section of "Chap 3, draft 11" -- it isn't
clear to me just what it is trying to accomplish. Does it imply that it
is illegal to define an :AFTER method on ALLOCATE-INSTANCE specialized
to, say, FUNCALLABLE-STANDARD-CLASS? If so, then I don't see the point
of it; but if not, then just what is it trying to say?
By the bye, is it a bug in draft 11, page 3-115, that the specified
methods don't specialize the second argument the same way as the other
SLOT-<mumble>-USING-CLASS functions do?
-- JonL --