Re: run-time method definition

["William D. Gooch" <ai.gooch@MCC.COM>]

    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.

	    Alternatives:
		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
approach.
                        
		    Con:    Extra complexity: closure required to "package"
			    application-supplied callback args. Deleting a callback
			    is harder. Prevents contact and callbacks from being
			    garbage-collected. 

    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.