[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: run-time method definition
Date: Tue, 11 Oct 88 11:10:49 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
William, can you elaborate on why you see this approach as more flexible and why
this is essential? This is a hot topic in CLUE-land, and we're trying to get to
the bottom of it.
I'll be happy to try. I should say first that I may have overstated
the case by using the word "essential" and should probably downgrade
that slightly to "very important."
For CLUE, defining callbacks as (eql instance)-specialized methods (instead of
functions looked up in an a-list instance variable) has been seen mainly as an
issue of packaging and of efficiency. Each technique gets the same job done.
Here's how the pro's and con's stack up so far.
a. A-list: add-callback: .... apply-callback ....
b. eql method: .... add-method .... generic-callback ....
Pro: Eliminates apply-callback and a-list lookup. Exploits CLOS
method dispatch. Contact programmer can define qualified
methods of callbacks.
This last is the added flexibility I was alluding to. As I understand
it, the programmer has to completely redefine an alist-indexed callback
function in order to change its behavior, whereas a method may simply be
qualified. I see this as an overriding advantage of the method-based
Con: Extra complexity: closure required to "package"
application-supplied callback args. Deleting a callback
is harder. Prevents contact and callbacks from being
The concern about deleting a callback is that it would involve remove-method,
but there's no find-generic-function, and find-method requires you to recall a
callback's full lambda list.
Another efficiency concern is method dispatch vs. small a-list lookup: which is
likely to be faster?
None of these potential problems seem particularly bothersome to me,
although I don't claim to fully understand the issues involved. I think
it would be very unfortunate to limit the robustness of the design just
for the sake of efficiency at this stage. What evidence is there that
the concerns mentioned reflect considerable drawbacks, and that there
are no workable solutions even if they do?
A tangential note which has occurred to me as I was writing this (I hope
someone on the X3J13 committee is listening) -- for the sake of CLUE, it
may be important that there exist a :within method combination (sort of
the inverse of :around). I won't go into detail here, since it's a
whole different discussion, but if the reasoning isn't clear, I can
elaborate under separate cover.