[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
change to instance structure protocol
- To: email@example.com
- Subject: change to instance structure protocol
- From: Jon L White <firstname.lastname@example.org>
- Date: Mon, 3 Dec 1990 21:17:51 PST
- Cc: Moon@stony-brook.scrc.symbolics.com, MOP.PARC@xerox.com
- In-reply-to: "Gregor Kiczales's message of Fri, 30 Nov 1990 15:12:29 PST <90Nov30.email@example.com>"
re: [the point of the restriction from p.13 of the July 30, 1990
metaobject protocol specification draft ??]
I thought I had answered this before, perhaps not. Think of this as the
natural analog of the Lisp Symbol Redefinition issue. It is trying to
make the method definition you propose illegal, and it is doing it
because that method is a "reserved word."
[You may have discussed this before, in the time period between OOPSLA '90
and your November 15 deadline for AMOP Part I comments; if so, then I
probably didn't read all that mail in detail.]
OK, I see what you are getting at -- it isn't just to enable the kinds
of optimizations for which the MOONS-LOOPHOLE class is a "breaker".
However, "Lisp Symbol Redefinition" may not be the the best design against
which to make an analogue. I don't feel comfortable at all with it, for
much the same reasons espoused earlier by Dick. For example, I can't see
any point at all to saying that the semantics of:
(DEFSTRUCT POSITION . . . )
must be undefined, just because POSITION is in the COMMON-LISP package
(because of its functional value). How, for example, does that help the
end user any more than saying that he cannot portably do:
(DEFSTRUCT USER::UPOSITION . . . )
?? There an always an implicit assumption that some other "portable"
program might want to define a structure on USER::UPOSITION so should this
symbol be off limits?? More precisely, adding cumbersome restrictions to
the "Language" in order to accomplish a goal for which the package system
was invented (i.e., end-user control over "imports" and "exports"), seems
like a totally misdirected effort. [Note that none of this bears on the
issue of forbidding a conforming implementation from making an extension
whereby COMMON-LISP:POSITION is given a defstruct definition.]
But AMOP Part II seems, to me, to begin a much more fruitful approach
towards setting up a true "protocol" (namely, saying when and under what
conditions such-and-such a definition is legal, and what it "means".) I
refer to the notions of "extending" and "overriding", and to the concept
of "interposed classes" and "promoted" methods for specified metaobjects.
Note that "extension" and "overriding", as "protocols", are not mechanically
checkable at definition time; but I don't see that as a problem. I *would*
see it as an stupid barrier if some implementation prevented me from defining
an :AFTER method on ALLOCATE-INSTANCE for standard-objects simply because it
is easy to implement that check.
-- JonL --