METHOD-INITFORMCALL-NEXT-METHOD and NEXT-METHOD-P be allowed in initforms for optional and keyword parameters and &AUX variables of methods? The document currently allows them only in the body of a method, not in forms embedded in the lambda-list, although it takes a close reading of the document to discern this.
There are two proposals in this issue.
This is Symbolics issue #15.
CALL-NEXT-METHOD and NEXT-METHOD-P to include all forms in a method, including forms embedded in the lambda-list.CALL-NEXT-METHOD and NEXT-METHOD-P includes only forms in the body of a method.(defmethod foo ((x myclass) &aux (y (call-next-method))) (if (null y) (zzz) (list ':baz y))) ;is briefer than (defmethod foo ((x myclass)) (let ((y (call-next-method))) (if (null y) (zzz) (list ':baz y))))
(defmethod countem ((x myclass) &optional (local (not (next-method-p)))) (let ((accum (if local 0 (call-next-method)))) (dolist (y (frobs x)) (incf accum y)) accum)) ;is briefer than (defmethod countem ((x myclass) &optional (local nil local-p)) (let ((accum (if (if local-p local (not (next-method-p))) 0 (call-next-method)))) (dolist (y (frobs x)) (incf accum y)) accum))
(defmethod jack-of-confusion ((x myclass)) (defmethod ace-of-confusion ((x myclass) &optional (y (call-next-method))) (borf x y)) (ace-of-confusion x)) ;In METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD, the default value for y ;is the value returned by an ace-of-confusion method. ;In METHOD-INITFORM:FORBID-CALL-NEXT-METHOD, the default value for y ;is the value returned by a jack-of-confusion method.
PCL appear to implement METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD. TI Explorer release 6 does not. Apple and IIM implement METHOD-INITFORM:FORBID-CALL-NEXT-METHOD.
The first example does not actually work in Genera due to a bug.
Other CLOS implementations were not surveyed.
METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD, handling CALL-NEXT-METHOD and NEXT-METHOD-P by simply wrapping a FLET or MACROLET around the body will not work. If they are called from forms in the lambda-list some massaging of the lambda-list is necessary. It's not very difficult, though.
METHOD-INITFORM:FORBID-CALL-NEXT-METHOD has no cost to implementors.
METHOD-INITFORM:FORBID-CALL-NEXT-METHOD forbids a programming technique that users might find useful. METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD requires a little more work for implementors, who might have thought they had finished their CLOS implementations by now.METHOD-INITFORM:FORBID-CALL-NEXT-METHOD avoids changing the status quo. METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD provides a programming technique that users might find useful.METHOD-INITFORM:ALLOW-CALL-NEXT-METHOD seems more uniform.CALL-NEXT-METHOD is allowed should be consistent with the places where RETURN from an implicit block is allowed. This probably supports FORBID-CALL-NEXT-METHOD.
Gregor Kiczales says he supports FORBID-CALL-NEXT-METHOD, but is not adamant about it. He thinks FORBID-CALL-NEXT-METHOD is more natural.