Re: Continuing comments on Draft 11

[Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.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
    are suggesting.

    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.