[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: method-lambda and apply-method-lambda
Date: Mon, 11 Apr 88 08:58:35 -0700
> APPLY-METHOD method next-method-info &REST arguments
I don't think this generic function is really necessary,
since APPLY, being itself
implementation dependent, could be modified to do the right thing given
a method function.
Jim, I think you must have missed the point. The problem isn't that what
APPLY does is implementation-dependent, but that the arguments to be passed
to APPLY are implementation-dependent. The most obvious case is the
next-method-info info; there is no way for APPLY to deduce this from the
other arguments, is there? If there is a way, I might change my mind on
suggesting a separate APPLY-METHOD primitive, but if there isn't a way,
we have to have that primitive so that the caller can supply the information.
Some implementations of APPLY
already must differentiate based on whether the function object is a closure
or not, since in the former case, the lexical environment must be
modified to reflect the lexical environment of the closure, so the
additional case of a method function is probably nothing new.
However, it might be useful for metaobject programmers who want a hook
for a metaclass specific way of applying a method. In that case, I think
the NEXT-METHOD-INFO argument could be dropped, since the concept of
a next method is specific to STANDARD-METHOD.
I disagree. I think CALL-NEXT-METHOD should be available to all classes
of methods that want it; I don't think it should be something magic for
The method metaclass method
for this generic function would then implement any special processing
for changing control flow.
I don't think I understand this last sentence; do you have a specific proposal?