Re: run-time method definition

[Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>]

   > Date: Tue, 11 Oct 88 08:29 CDT
   > From: William D. Gooch <ai.gooch@MCC.COM>
   > Subject: LISP X based toolkits 
   > 
   >     Date: Tue, 11 Oct 88 17:25:07 JST
   >     From: Haruyuki Kawabe <kawabe@etl.jp>
   > 
   >     But it seems to me that it is too heavy in most implementations to add
   >     or remove methods at run time because of re-hashing of a method table
   >     or similar things in order to speed up of generic-function callings,....
   > 
   > It seems
   > to me that it's absolutely essential to have this kind of flexibility as
   > a CLUE user...

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.

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: add (name function . args) to callbacks
                a-list. apply-callback looks up and calls function associated
                with name.

            b.  eql method: (make-instance 'standard-method ... :function
                function :lambda-list `((eql ,contact) ...)) creates a callback
                associated with a contact instance. (add-method generic-callback
                method) adds this method to a generic function. Callback is
                invoked by calling generic-callback with contact as specializer
                arg.
                        
                Pro:    Eliminates apply-callback and a-list lookup. Exploits CLOS
                        method dispatch. Contact programmer can define qualified
                        methods of callbacks.
                        
                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?