[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MAKE-METHOD-FUNCTION and APPLY-METHOD
- To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: MAKE-METHOD-FUNCTION and APPLY-METHOD
- From: kempf@Sun.COM
- Date: Thu, 14 Apr 88 13:44:07 -0700
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Your message of Thu, 14 Apr 88 15:01:00 -0400. <19880414190146.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
>The method combination can be obtained from the generic function by
>calling generic-function-method-combination, so the only reason to
>pass it as an argument to compute-discriminator-code is if it's needed
>for method selection.
Right, so it can go back to just one parameter.
>I see. Here's another way to write it that might make what you're doing
>easier to understand:
> (defmethod compute-discriminator-code
> ((generic-function standard-generic-function))
> (let ((f (get-handler-for #'compute-effective-method
> #'(lambda (&rest args)
> (let* ((applicable-methods
> (compute-applicable-methods generic-function args))
> (funcall f generic-function
> applicable-methods)) ....
>get-handler-for is a new primitive that provides a proper separation
>between the act of finding the effective method function and the act of
>applying it. This pulls the generic dispatch for
>compute-effective-method out of the loop. This is mere code hoisting,
>except that it shows where to put the special case to break the
Yes, this would be a more general primitive. This looks good.
Reactions from others? Patrick, Gregor? It would be particularly interesting
to hear how people feel about letting compute-discriminator-code and
make-method-function negotiate their own contract for the calling interface
in method metaclasses other than the default.