[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
no-next-method lexical function
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. The full text of the comment was:
From email@example.com Thu Apr 14 15:32:01 1988
Date: Wed, 13 Apr 88 17:05:24 JST
1. About the error signaled when next method doesn't exit.
The CLOS spec intends the user should check whether the next method exits
by next-method-p, but it will degrade the modularity, because the user
should concern about his method might have a method with the same name
which discriminate on the super class or combined with method combination.
In the system where multiple inheritance is supported, next method of
some method doesn't mean one unique method. There is a case where same
method have a next method in on case, and there isn't next method in another
case, depending on the context. (On the other hand, in Smalltalk 'super'
method can be decided statically). The method combination facility further
complicates the decision whether next method might be exit. This might
enforce the user should always use next-method-p.
To solve this problem, Object System should call a generic function named
such as 'no-next-method', when call-next-method is invoked but there isn't
such method, and the default method of 'no-next-method' should signal an
error. With this modification user can write 'no-next-method' which does
nothing or invokes error notifier. This mechanism is the same as
This is a good idea. We should add a generic function called
NEXT-METHOD-MISSING which receives the generic-function, method and the
arguments as its arguments.
(defmethod next-method-missing ((gf standard-generic-function)
(error "No next method"))
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.
I agree that no-next-method is a better name. The method I propose it
receive as an argument is the currently executing method. This gives
specializations of no-next-method which want to try to determine which
method to invoke more information to work with.
What do others think? (Heard this line before anywhere?)