no-next-method | no-applicable-method

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

I think we are all agreed that CALL-NEXT-METHOD, when there is no next
method, should call a user specializable generic function, rather than
directly signalling an error as 88-002 says.  The only point of contention
is what should the name of that generic function be.

    Date: Fri, 29 Apr 88 14:30 PDT
    From: Gregor.pa@Xerox.COM

    One of the comments we received complained that there was no defined
    protocol for what happened when call-next-method was called and there
    was no next method....

    Moon said:

    NO-NEXT-METHOD is a more consistent name.  I don't understand what method
    you propose it would receive as an argument; I think it should receive the
    same arguments as NO-APPLICABLE-METHOD.

    Gregor said:

    I agree that no-next-method is a better name.  The method I propose it
    receive as an argument is the currently executing method.

I think what you mean is more precisely stated as: the method that
created the local definition of call-next-method that had no next
method.  Because closures of call-next-method can be passed around
as funargs, this may not be the currently executing method at the
time NO-NEXT-METHOD is called.

    Date: Mon, 2 May 88  09:33:56 CDT
    From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>

    I think the concept of NO-NEXT-METHOD is fine. I don't have any
    opinions about the method argument. I'd like to see David's objection
    to it.

I withdraw my objection now that I understand what the argument is.

    Date: Mon, 02 May 88 09:00:39 -0700
    From: kempf@Sun.COM

    This seems like a special case of no-applicable-method....

    Date: 03 May 88  1315 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    ....
    These sound as if the problem is that there is no applicable method.

    Date: 3 May 88 14:50 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    I think the critical issue here is that for intelligent error handling,
    different arguments are necessary for NO-NEXT-METHOD and NO-APPLICABLE-METHOD.

    Date: Wed, 04 May 88 08:42:20 -0700
    From: kempf@Sun.COM

    (defmethod no-applicable-method ((method standard-method) &rest arguments)

      (error "No applicable method for CALL-NEXT-METHOD from method ~S having~
	      argument list ~S.~%" method arguments))

Depending on one's personal sense of programming style, this clever
trick is either a good simplification of the language by avoiding
introducing two names where one will do, or a vile pun that confuses two
concepts that should be separate.  This can be seen as analogous to some
users' objection to CLOS method argument list congruence rules, on the
grounds that a single generic function ought to be usable with two
disjoint families of classes where the methods take different arguments
and that CLOS is wrong to force the programmer to choose two different
names.  In any case I believe this is only an issue of naming and that
the same application programs can be written no matter which way CLOS
goes on this issue.

I have no strong opinion on this issue.  My own sense of programming
style dictates that in any program I wrote, two separate generic
functions would be used.  However, I think the other programming style
is a perfectly legitimate style, and I have no strong opinion which
style CLOS should adopt.  I will point out however that I am unable to
think of any other cases in which CLOS has used a single generic
function specialized to two disjoint families of classes (in this case,
generic functions and methods).  For example, 88-003 proposes separate
class-name, slot-description-name, and generic-function-name functions,
rather than a single function called metaobject-name, standard-object-name,
object-name, or name.