no-applicable-method

[Jon L White <edsel!jonl@labrea.stanford.edu>]

re: With no-next-method, the user can do something like:
    . . . 
    (defmethod no-applicable-method ((gf standard-generic-function)
				     (m my-method)
				     &rest ignore)
      nil)

Didn't you mean (defmethod no-next-method ...)?

Danny's point is well taken: NO-APPLICABLE-METHOD is one kind of error, and 
it is useful when debugging to get a different kind of error when there *are* 
applicable methods, but some one of them presumes that there are more in the
method list than actually are there (i.e., CALL-NEXT-METHOD runs out).  His
argument is based on the variation in number of arguments passed, and your
example exploits essentially this.  But I think there is a more fundamental 
case that can be made for keeping the two "error" functions separate. 

In the first case, one would think of repairing the error by adding some 
defmethod somewhere to cover a missing case, or to change a some caller
who is passing an "illegal" value.  But the second kind of error takes one
into a much more complex domain -- involving more advanced concepts such
as method combination and possibly meta-object protocols [perish the
thought that call-next-method failed in a function that really wasn't
a standard-generic-function, or where the method combination was someone's
hallucinative speciality).  Even if you could cram one interface into
the other, by passing differing arguments or whateer, it would be a less 
desirable user interface.


-- JonL --