[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Continuing comments on Draft 11
- To: gregor@parc.xerox.com, Cyphers@JASPER.SCRC.Symbolics.COM
- Subject: Re: Continuing comments on Draft 11
- From: Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>
- Date: Fri, 2 Nov 1990 14:23:00 PST
- Cc: jonl@lucid.COM, mop@arisia.Xerox.COM
- In-reply-to: <90Nov2.134736pst.230@spade.parc.xerox.com>
Date: Fri, 2 Nov 1990 16:47 EST
From: Gregor Kiczales <Gregor@parc.xerox.com>
I am not sure I understand either of your comments, but I have a
question that may clarify them for me. Are you implicitly assuming that
any user methods on make-method lambda would call CALL-NEXT-METHOD as in
my example. That is, are you assuming that the ultimate value returned
by MAKE-METHOD-LAMBDA would have been produced by an implementation
method?
Yes.
If so, that would mean that I couldn't write call-next-method or
next-method-p for myself.
Oh, so that's what you want to do. I'm not exactly sure how anyone
would use that, but I guess it doesn't matter. The information about
next methods is a cooperative effort between the stuff that makes a
combined method (the thing that you really dispatch to) from an
effective method and make-method-lambda. The way we have these two
things communicate is with the second value returned by
MAKE-METHOD-LAMBDA.
Suppose one of the things returned is :NEXT-METHOD-TYPE. NIL would mean
that the method doesn't want this information. Another value might be
CLOS-INTERNALS::THE-WAY-I-DO-IT, for normal CALL-NEXT-METHOD. If you
wanted to do it some other way, you'd return GREGOR::MY-WAY. I guess
there'd have to be a macro (only defined in methods) of no arguments
called something like NEXT-METHODS which let you get hold of the list of
next methods that your method combiner was passing to you (since
each implementation will probably have a different way to do pass the
information into the method).
We use a generic function like this:
(DEFMETHOD METHOD-FUNCTION-NAME-AND-EXTRA-ARGUMENT
((GENERIC-FUNCTION STANDARD-GENERIC-FUNCTION)
(METHOD STANDARD-METHOD)
NEXT-METHOD-FUNCTION
ARGUMENT-FUNCTION
&REST KEYS)
(DECLARE (IGNORE KEYS))
(VALUES METHOD
(COND ((METHOD-NO-NEXT-METHOD-INFORMATION METHOD)
(METHOD-MAPPING-TABLE METHOD ARGUMENT-FUNCTION))
(T
(MULTIPLE-VALUE-BIND (NEXT-FUNCTION-NAME NEXT-EXTRA-ARGUMENT)
(FUNCALL NEXT-METHOD-FUNCTION)
(LIST* (METHOD-MAPPING-TABLE METHOD ARGUMENT-FUNCTION)
(FDEFINITION NEXT-FUNCTION-NAME)
NEXT-EXTRA-ARGUMENT))))))
to do help make the combined method. NEXT-METHOD-FUNCTION generates the
information for the next step in the chain, I hope this isn't too
cryptic for understanding. The cond would have to be generalized;
perhaps the value of :NEXT-METHOD-TYPE would be the name of a function
to be called with arguments, and the COND would be eliminated, or
something like that.
By the way, the argument function is a function of which you can ask
questions about the provided arguments, such as their actual class or
value. This is how we get the right mapping table. We'd have to change
this a bit to handle other kinds of specializers, but that's a different
can of worms.