Re: [Gnome-bindings] Ok, here we go...

[Karl Nelson <kenelson ece ucdavis edu>]

> 
> One thing you did not put on your list, and that is used heavily at least in
> the GtkAda binding is that each time a function takes a "user_data" (this is
> true for callbacks and a few other functions like idle and timeouts), it
> should provide two versions:
> 
>     gtk_connect (foo, gpointer user_data);
>        /* for C users' convenience */
> 
>     gtk_connect_full (foo, gpointer user_data, DestroyFunc);
>        /* for bindings convenience */

Actually here I should point you to my original closure proposal.
It is not exactly what they plan to use, but close enough to show
you how closures solve you problem.

  http://www.ece.ucdavis.edu/~kenelson/closure.txt

Every function which currently takes a callback including things
like foreach will get a closure version.  

So while gtk_connect is for C users, there will be a gtk_connect_closure
for our uses.

  gtk_connect_closure( foo, GtkClosure* );

A closure is a binders dream.  It contains everything a non-C
user could want including a Args Vector callback point, a C function
callback point,  a user data pointer, and a destroy notification.
It works by placing a 0 in the Args Vector callback, it will insert
one which calls the C function.  Thus gtk+ will collect things
into lists and pass it over to the args vector which in turn can call
a Perl untyped system or a C++ strongly typed system.  The closure
is reference counted and is arranged to be virtual so that 
binders can derive and add as much data as is needed.  

Note, that the only part which was rejected from my proposal was
the forced destroy function, meaning they don't want to spend
the space to do dependency tracking.  (If we really want such 
functionality,  we will need to force the issue.)

 
> It allows the bindings to copy an internal structure compatible with a
> gpointer, even if the real type in the binding is not, and still get the
> memory management done by gtk+.
> 
> For instance, Strings in Ada are not fully compatible with gchar*, since they
> also include bounds information. Thus, we do a copy internally that is
> compatible with a gchar*/gpointer, and free the allocated memory whenever gtk
> +
> calls DestroyFunc above.

Definitely addressed in the closure.  

 
> I believe that gtk+ is mostly clean in that regard, I haven't looked carefull
> y
> at Gnome yet, and I know that gtk+extra is not compatible.

Gtk+ is not really that clean.  The gtk+ signal connect has
like 10 forms which can do anything from swapping the data to
disconnecting at a specific time.  When you get to
idles that falls to 2 forms, then in foreach and other places to 1.
(By the time you get to GNOME, most things are totally C methods
with no sign of the abstraction signals have.)

I hope the everyone takes a minute to read over the closure and
make sure it has what they need.  The closures are largely there
just for us.  It is still in design stage was TimJ codes 
up the object system.

--Karl