[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Continuing comments on Draft 11
- To: firstname.lastname@example.org, Cyphers@JASPER.SCRC.Symbolics.COM
- Subject: Re: Continuing comments on Draft 11
- From: Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>
- Date: Sat, 3 Nov 1990 13:00:00 PST
- Cc: jonl@lucid.COM, mop@arisia.Xerox.COM
- In-reply-to: <90Nov2.email@example.com>
Date: Fri, 2 Nov 1990 20:37 EST
From: Gregor Kiczales <Gregor@parc.xerox.COM>
The stuff you sent back was so implementation specific that I am not
sure I understood it. Let me try to propose something like what you
Add a new lexical function to the body of methods, this lexical function
can be used to access the value passed in as the second argument when a
method function is called.
Not "as the second argument", but roughly equivalent to the second
argument you were proposing.
Add a second returned value from make-method-lambda. This value is a
symbol which describes what the method expects to find in the second
argument to method functions.
make-method-lambda already returns a second value, a plist. I'm just
defining one of the properties.
But, what does this get me? How can I extend the space of what the
second argument/value are for. Because the second value returned by
make-method-lambda is a symbol, and it disappears into the bowels of
the implementation, I can't use OOP to tailor what it means.
No, the second argument isn't supposed to be something that disappears
into the bowels. It's a message to a missing part of MOP to tell that
part how the method is expecting to receive information like the next
methods (one can imagine someone wanting to have a call-previous-method
(maybe in some backtracking system) and a call-next-method in the same
function, or maybe even a call-other-message to get into some other
stream of methods, which your scheme can't support). By specifying
things like method-functions this early, without having specified the
rest of the method combination mechanism, I think we seriously risk
losing future flexibility. My second implementation of method
combination (not the one in 8.0) gave me hope that something like this
could be done, preferably in a way that can express the approaches taken
by the current CLOS implementations. November 15th is too soon for a
description to be worked out (although I'd be glad to prototype one when
I can find the time).
I actually don't think that extending the space of what dynamic
information can be passed into a method is going to be tractable given
the current MOP. It depends on a lot of stuff. For example, I think
you would want to attach to compute-applicable-xxx, otherwise you
wouldn't have a basis for caching.
Right, that's why I don't think we should be saying what the arguments
to a method function are going to look like at this time. Let's make
sure the whole generic function picture is going to work before
pseudo-standardizing a part of it.