[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: call-next-method is not a function
- To: Common-Lisp-Object-System@sail.stanford.edu
- Subject: Re: call-next-method is not a function
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 6 Feb 87 23:27 EST
- In-reply-to: <870206-133321-3786@Xerox>
Date: 6 Feb 87 13:34 PST
From: Masinter.pa@Xerox.COM
Perhaps it is unavoidable, but the possible indefinite extent of the
call-next-method function also exposes another issue, which is whether
identity of the "next method" is closed over, or dynamic.
In the same example, given
(defclass wozzle (nozzle))
(defmethod test ((a wozzle)) #'call-next-method)
(defmethod test ((a nozzle)) "Nozzle tester")
(defvar *nozzle-tester* (test (make-wozzle)))
(defclass big-nozzle (nozzle))
(defclass wozzle (big-nozzle)) ; redefines wozzle
(defmethod test ((a big-nozzle)) "Big nozzle tester")
; whew...
(funcall *nozzle-tester*)
Does this get "Nozzle tester" or "Big nozzle tester"?
The issue is "what's closed over" in the call-next-method.
In my trial implementation I did back in September, it closes over everything
and the answer is "Nozzle tester". But if you read the Remarks field of
change-class (in the 31 Jan version), this situation is already explicitly
undefined (the "first semantic difficulty") if we merely extend "the execution
of a method" to include the lifetime of any call-next-method closures it creates.
So let's just add a sentence there mentioning call-next-method closures. This
includes not only #'call-next-method, also #'(lambda .... (call-next-method) ...),
thus the problem was not introduced by changing call-next-method from a macro
to a function.
A related issue, which I think should be explicitly defined, is to make clear
that
(defmethod ...
(dotimes (i 100)
(call-next-method)))
calls the same method 100 times. It does not call the 100 next most specific
methods (erring if there are fewer than 100).