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.
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
