[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> Alternatively, no-applicable-method could search the argument list
> element of the forwarder class to send the message to, else signal
> This would not make it so dependent on the first argument.
This discussion of forwarders implemented using no-applicable-method is
slipping between classical (first arg) forwarders and multi-method
forwarders. The classical case is pretty well-understood but doesn't
fit with CLOS (as responses to your first proposal pointed out). Here
you are proposing that forwarding happen on the first argument which is
an instance of forwarder class. What's special about the first one?
Forwarding should happen only when the object is actually involved (in
actor terminology -- receiving a message). The first argument which is
an instance of the forwarding class may passed around only to use under
extraordinary conditions (e.g. an error stream) or might be there to
embed in a structure (forwarding should not happen then).
Not only is it possible to start forwarding too soon, but one may miss
cases in which forwarding was intended. A generic function may have a
default method, or have methods that have T specifiers where the
forwarders are possible. no-applicable-method may never get called. An
elegant, but too expensive, solution is to define forwarders as classes
as not under T.
Forwarders are of limitted utility if they only work for generic
functions and not for ordinary functions. CLOS correctly hides that
distinction from callers. But I haven't heard anyone proposing that
ordinary functions call no-applicable-method when they get wrong-type
Another worry I have about no-applicable-method is that it's piggy
backing upon what is essentially an error mechanism
(no-applicable-method). This seems to be a bad idea. (I remember a
lunch discussion during IJCAI-85 about forwarders and CommonLoops. Kent
Pitman argued well against forwarders using such a mechanism.
No-applicable-method may get called when forwarding is inappropriate
(e.g. buggy code).)
Finally, I think one has to be concerned with the efficiency of an
implementation of forwarding where arguments are consed together,
searched, spread out and several generic functions are called.
Bobrow's message of Fri, 2 Oct 87 13:50:00 PDT -- Re: