run-time method definition

[Haruyuki Kawabe <kawabe@etl.jp>]

   >Sender: KK@sierra.csc.ti.com
   >Date: Tue, 11 Oct 88  11:10:49 CDT
   >From: 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,....

Excuse me, only adding (eql instance)-specialized methods to a generic
function is not so heavy. Please ignore my opinion above.

   >		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.
   >			    
   >		    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.

So callback methods should take only one argument which is (contact
(eql instance)) and other application-supplied data are closed using
closures when these methods are created. Then you can easily find your
method. (Generic-function objects could be refer by (FUNCTION
generic-function-name)) Moreover a clousre is stronger and more
convenient than passing application-supplied callback args using
ADD-CALLBACK when they changes frequently.


	Haruyuki Kawabe
	Knowledge System Department
	Nihon Unisys Ltd.
	2-17-51 Akasaka, Minato-ku, 
	Tokyo 107, JAPAN  
	e-mail: kawabe%etl.jp@relay.cs.net