CALL-NEXT-METHOD

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 7 Jan 88 18:32:38 PST
    From: Jon L White <edsel!jonl@labrea.stanford.edu>

    re: funcall-qua

    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.