[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
run-time method definition
>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 <email@example.com>
> > 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
> 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.
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.
Knowledge System Department
Nihon Unisys Ltd.
2-17-51 Akasaka, Minato-ku,
Tokyo 107, JAPAN