Re: Continuing comments on Draft 11

[Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>]

    Date: Sun, 4 Nov 1990 18:54 EST
    From:	Gregor Kiczales <Gregor@parc.xerox.COM>

    The idea is to say that the 2nd, 3rd (and so on) `arguments' to
    CALL-METHOD become the 2nd, 3rd (and so on) arguments to method
    functions.  (An extension from the current scheme where the second
    argument to CALL-METHOD is a list of next methods and the second
    argument to method function is the list of next methods.)  Users who
    want to pass more dynamic information to methods can do so by altering
    MAKE-METHOD-LAMBDA and COMPUTE-EFFECTIVE-METHOD.

This extension would be okay, although I'm not sure about the okayness
details of how the call-method arguments get passed to the method
function.

Users defining their own kinds of methods would pay a substantial price
in performance.  When not using anything in MOP, a call-method in my
implementation consists of a couple cars and cdrs and a simple function
call (I do all the METHOD-FUNCTION kind of stuff during method
combination.  I also know what the arguments look like at that time,
which is important for things like mapping tables).  The MOP user would
have to check the list of next methods, and either call METHOD-FUNCTION
or NO-NEXT-METHOD as appropriate, cons the method arguments into a list,
etc.  There's mo room for a valid CL compiler to do much optimization
there either, since argument passing conventions are a cooperative
effort between the caller and the method being called.  I want MOP users
to be able to get the same kind of performance they get from the non-MOP
stuff.

If METHOD-FUNCTION knew the method and the arguments and returned a
function and some description about the kinds of arguments that the
function could be used with, then I think we might be closer to
agreement (Jonl might even start to agree with it) although I think it's
also going to be necessary to call the method function with something
other than funcall or apply.  We'd still have the next method
information to deal with; having methods in there is going to be slow.
Having something like what method-function returns would be better, but,
again, you really want the method combinations and the methods to come
to an agreement about what's in there, since it's not the kind of thing
you can optimize based on local information.