Jan Rychter wrote:
What are the problems with unnamed callbacks? My guess was that they will never get garbage-collected, but how about storing all
of these in
a table somewhere and explicitly freeing them after they are
no longer
needed? In my case I do have a way of finding out when a
callback is no
longer needed, and I suspect this is the case for many other applications.
Martin Simmons wrote:
The function evas_object_event_callback_add already makes a closure -- on the C side.
Good observation. So maybe, if CFFI will not provide an unnamed callback API via #+cffi-features:xyz, maybe it could encapsulate this into a pattern and provide that?
The pattern is that many callbacks (AFAIK, all GUI callbacks), provide some void* data thing that can be used as an indexing scheme as Martin Simmons from Lispworks describes (coincidentally IIRC, Allegro's documentation also mentions indices somewhere, and if you dig into CLISP, you'll find some to :) That could be put to use, together with a CFFI API for freeing the indices & callbacks.
The one true callback would be a CFFI-internal one, named, which dispatches to registered closures. In fact one would need a family of such named callbacks, presumably one per function signature (e.g. cb(void*data,int,xyz*) etc. -- Uh oh. So there's maybe a need for a callback generator (macro writing macro). But possibly only one per GUI toolkit :-)
Beside that, cffi-features:no-lambda-callback might be an independent API to add (together with a means to free them, if provided). I'd expect more than half of Lisps to have unnamed callbacks.
In the long run, with dozens of optional interfaces, CFFI code will look like C preprocessor code, with all those #+ #-cffi-feature:foobar...
BTW, I just realize that ANSI-CL got it right, and CFFI got it wrong IMHO: the keyword package is named #:keyword, not KEYWORDS. Because you refer to a single one each time.
Regards, Jörg Höhle.