[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: method-lambda and apply-method-lambda
> 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.
Why does the next method info have to be passed as arguments to APPLY or
an APPLY-like function in the first place? I thought the whole purpose of
MAKE-METHOD-FUNCTION was to return a function for which that information
has already been installed in the (some) environment, or maybe I'm missing
something. And that NEXT-METHOD-INFO gets it.
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
No, I didn't mean to imply that CALL-NEXT-METHOD would be magic. Look,
here's my vanillia implementation for MAKE-METHOD-FUNCTION for STANDARD-METHOD:
( (call-next-method (&rest args)
(if (check-args args ',specializers)
(apply (get-next-method-function ',proto-method) args)
(apply #'no-applicable-method ',generic-function args)
The only "magic" here is GET-NEXT-METHOD-FUNCTION, and I can't think
of any other way to keep track of the next method function unless
the method knows about it's next method itself
(though there may be some ways to speed
up getting it, but this is a specification). Is there something
I'm missing here?
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?
(defmethod apply-method ((method standard-method) &rest arguments)
(apply (method-function method) arguments)
Other metaclasses might want to control method application via their
method metaclass object, but the default would be not to.
I think I've got a different (and perhaps wrong?) model about what's
going on. My model is that MAKE-METHOD-FUNCTION constructs a function
in which the metaclass dependent specialized control flow primitives
(e.g. CALL-NEXT-METHOD) are part of the lexical environment
seen by the user code (LAMBDA-EXP). Any other system dependent
information needed to influence control flow (e.g. permutation tables)
would also need to be included, but naming access controlled so only system
code sees it. NEXT-METHOD-INFO, or whatever the accessor function
is named, is able to get at that information in some implementation
dependent way. Thus, the method function should be invokable via
APPLY, with APPLY-METHOD more of a utility should a metaobject user
happen to have a method and not want to retieve the function.
want to use it. No hidden arguments to APPLY needed.
Anyway, let me know if this is making sense, or if it's only a result
of allergic reaction to springtime pollen.