From 9726da802284076a486e23a5d09b7920f1260b8f Mon Sep 17 00:00:00 2001 From: Søren Sandmann Pedersen Date: Mon, 13 Apr 2009 21:46:30 -0400 Subject: TODO --- TODO | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/TODO b/TODO index c154ca1..2c7556c 100644 --- a/TODO +++ b/TODO @@ -61,11 +61,34 @@ passed to the function would go. Maybe that would just always go first. Ie., void on_clicked (void) { - printf ("clicked\n"); + printf ("clicked\n"); } Would require a dependency on macro varargs and on libffi closures. +libffi closures are not a problem. They are supported for all +relevant, and several irrelevant, architectures. Macro varargs - the +main issue might be msvc. Actually, it doesn't have to be a macro, it +could be a vararg function. It would require some way to specify the +end of the argument list though. Or just give the number of arguments: + + NUL_CALLBACK (function, 2, NUL_INT (x), NUL_INT (y)); + +If the NUL_INT constructors return a pointer, it would be easy to +check at runtime that the number of args is not an insanely big number +(say > 100 or < 0). + +If all callbacks are defined as trampolines, then it is possible to +have them be a struct with an optional destroy notifier embedded in +it. Ie., the NUL_CALLBACK would do something like this: + + nul_callback_info_t *info = malloc (sizeof (...)); + info->f = make_closure (f, ...); + info->destroy = free_callback_info + +where free_callback_info would free the closure and the callback info +plus any other house keeping. + Dbus: @@ -356,7 +379,7 @@ Highlevel design for a web server: nul_object_block (object, "birnan"); nul_object_unblock (object, "birnan"); - nul_object_connect (object, "birnan", on_birnan, DATA); +/ nul_object_connect (object, "birnan", on_birnan, DATA); */ -- cgit v1.2.3