[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
method-lambda and apply-method-lambda
- To: Gregor.pa@Xerox.COM
- Subject: method-lambda and apply-method-lambda
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 11 Apr 88 20:55 EDT
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: <880411161708.3.GREGOR@SPIFF.parc.xerox.com>
- Line-fold: No
There's something missing from your message. Isn't the only reason
make-method-function and apply-method were proposed (by you originally,
Gregor) to allow users to interject code between the method lookup and
the method invocation, for instance when tracing? Otherwise there would
be no need to standardize these little pieces of the implementation of
generic functions when we don't standardize all the rest of it.
So I think the abstraction barrier isn't between method lookup and
method invocation, but rather between those two mechanisms on the one
hand and user-written code on the other. But this only says why these
two functions should exist, not whether they should be generic or not.
I agree that the method lookup mechanism and the method invocation
mechanism need to understand each other in detail. What I don't
understand is how that has any bearing on whether or not these two
functions should be generic, i.e. whether or not there should exist
more than one method invocation mechanism. I guess I don't understand
PCL's compute-discriminator-code generic function, since I don't
understand how specializing that could affect what parameters the
compiler makes a method-function accept.
In conclusion, while I agree with all of your message that I understood,
it doesn't seem to me to have any bearing on the issue it was supposed
to be about. Obviously I missed something big that you thought was there.