[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Jon L White <email@example.com>
- Subject: CALL-NEXT-METHOD
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 11 Jan 88 20:22 EST
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: <8801080232.AA19088@bhopal.lucid.com>
Date: Thu, 7 Jan 88 18:32:38 PST
From: Jon L White <firstname.lastname@example.org>
In the smalltalk-like object system that Bob Kerns and I did for PDP10
MacLisp and NIL in 1980 (called the EXTEND feature), we actually included
a primitive named SEND-AS. This function took just one more argument than
SEND, and defeated the CLASS-OF lookup that a normal SEND would do; it
supplied the starting point for method-lookup directly.
You copied SEND-AS from the class system extant on the Lisp Machine at the
time (I'm not complaining, that was a perfectly reasonable thing to do).
Later on, SEND-AS was discredited as a bad idea that just turned programs
into messes. At least, that was the experience of the Lisp Machine folks.
I realize that with multi-methods and generic functions, the syntax for
such a thing would be tricker -- maybe not even workable at all. But the
actual use of SEND-AS was for "delegation"; and if that is the intended use
that Kempf and Gabriel have in mind, then perhaps a more limited extension
is all that is needed.
Let me be very clear: I don't think the problem with SEND-AS is the
syntax. I think the problem is that it is a way to name a function that
is different from the normal way to name functions. Instead of SEND-AS,
I prefer to say that if two methods have a subroutine in common, that
subroutine should be given a name with DEFUN in the normal way and then
they both should call it. In that old class system, and in all versions
of Flavors I am aware of, the body of a method can do things that the
body of a function can't, such as reference instance variables, which is
the argument for having a special way to name subroutines of methods
that is different from DEFUN. CLOS has fixed that.
I believe that no extension to CALL-NEXT-METHOD is desirable.