[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

scope of call-next-method



    Date: Wed, 11 Nov 87 14:51 PST
    From: Gregor.pa@Xerox.COM

    This message concerns the scope of call-next-method and next-method-p.
    Recent drafts of the spec say that the scope of these functions include
    the default value forms for optional and keyword arguments.  I believe
    that the scope of these should include only the body of the method.
    I don't see how what the spec currently says can work.  The problem is
    that call-next-method is defined to have access to the bindings of the
    arguments to the method.  

No.  Call-next-method has access to the arguments.  It explicitly does not
access the bindings of the parameters (-not- arguments) of the method.

			      But if call-next-method is called during the
    process of doing those bindings what arguments will it have access to?
    What arguments will it pass to the next method?  

I think you've been misled by the arguments/parameters terminology.
Even though I'm pretty sure CLtL uses those terms consistently, and I
think the CLOS spec does as well, in informal talk people still often
get them mixed up, and the two words sound so similar that this is not
surprising, especially since other languages use other terminology.

Here's a simple example of a way to implement it, although I imagine
most implementations would find another way that is less simple but
more efficient in that particular implementation.  Several obvious
improvements to the below will immediately spring to your mind.
For instance, it isn't necessary to use &rest.

(defmethod foo ((x boat) &optional (y (call-next-method)))
  (body x y))
==>
(add-method ...
  (make ...
    #'(lambda (... &rest #:arguments)
	(flet ((call-next-method (&rest #:c-n-m-arguments)
		 (apply ... (or #:c-n-m-arguments #:arguments)))
	       (next-method-p () ...))
	  (apply #'(lambda (x &optional (y (call-next-method)))
		     (body x y))
		 #:arguments)))))