[non-conformance] closer-mop shadows call-next-method in make-method-lambda about closer-mop

[pcostanza]

The "restrictions on redefinition and shadowing" are specified in Section 11.1.2.1.2 of the HyperSpec. It states that "except where explicitly allowed," it's not a good idea to redefine such symbols. This exception is important.

The CLOS MOP specification defines such an exception for call-next-method. See http://www.p-cos.net/lisp/mop/mop/dictionary.html#make-method-lambda where it states that make-method-lambda "can be overridden." (What it means for a method to be overridden is specified in http://www.p-cos.net/lisp/mop/mop/concepts.html#implementation-and-users - namely that a user-defined method does not have to return the result of call-next-method, or does not even have to call it.)

The section on make-method-lambda also shows that it is clearly the intention that user-defined methods can introduce new local definitions for call-next-method and next-method-p. See from the same entry: "Note that the system-supplied implementation of call-next-method is not required to handle extra arguments to the method function. Users who define additional arguments to the method function must either redefine or forego call-next-method." See also the example given there.

I believe that a Common Lisp implementation that claims to conform to the CLOS MOP specification should respect this exception.

[dkochmanski]

good point, thank you for pointing that out. This one was my biggest concern with regard to the proxy generic function metaclass.