[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CALL-NEXT-METHOD Winter Solstice present
We redid the algebraic specification for CALL-NEXT-METHOD to
include arguments, as the current draft of the spec allows, and the
wording of the spec seems to allow too much latitude in the
semantics. The current spec says this (pg. 2-9 in my copy):
When CALL-NEXT-METHOD is called with arguments, the
next method is called with those arguments. When providing
arguments to CALL-NEXT-METHOD, the following rule must be
satisfied or an error is signaled: The ordered set of methods
applicable for a changed set of arguments for CALL-NEXT-METHOD
must be the same as the ordered set of applicable methods for
the original arguments to the generic function. Optimizations
of the error checking are possible, but they must be invisible
to the programmer.
The problem is that there is no precise definition of what
"next" method means in this context.
This paragraph is taken out of context. The "next" method is always the same
(defined in the purpose section of the writeup). There is a list of methods
determined by the initial arguments to the combined method. The next method is
determined by the order of methods in this list (ordered from most to least
specific). The next method is always the method in the list after the method
containing the call to call-next-method.
The intent of the paragraph above is to indicate that if arguments are provided
to call-next-method, the list of applicable methods, and order of specificity
must be the same as the original list. This preserves the semantics of the
call. The next method after the one containing the call to call-next-method in
the original list of applicable methods will be identical to one determined the
same way from a newly computed list. NOTE call-next-method never can call a
method earlier on that list.
Consider the following example. A generic function, GF is
invoked with the argument list AL. The computation of the effective
method yields the list of applicable methods ( M(0) M(1) M(2) M(3)
M(4) ). For simplicity's sake, say that they are all primary
methods (i.e. no daemon methods).
Say that M(0) invokes CALL-NEXT-METHOD with no arguments, M(1)
does also, and M(2) invokes CALL-NEXT-METHOD with precisely the
arguments which it was passed. The sorted list of applicable
methods won't change, but the "next" method will be M(0), since it
is the next matching method on the list.
Wrong. It will be M(2). Remember the rule is the same as it was earlier.
Now say that M(2) invokes CALL-NEXT-METHOD with a list of
arguments, the classes of which match the parameter specializers
for M(1). The sorted list of applicable methods for this call is a
truncated version of that for the original invocation (the CDR, in
fact). Would that be an error?
YES. It is just this case that the paragraph in question was trying to outlaw.