Re: simplifying closures

[Karl Nelson <kenelson ece ucdavis edu>]

> Karl Nelson <kenelson ece ucdavis edu> writes:
> 
> > 
> > >  - we haven't actually mapped out when C programmers are going to 
> > >    use these features, how they will use them, etc. i.e. 
> > >    we seem to be starting with an implementation and not 
> > >    by outlining the use cases and the API that would be convenient in 
> > >    those cases.
> > 
> > I provided the first map to Tim and Owen.  However, as my map 
> > was not close to the final one, I didn't feel it was a good idea to
> > release it.  Tim is just now got the ideas straightened out enough
> > to say waht a clousre system needs to have in terms of internals. 
> > 
> > My argument on when and where are C users are going to use closures
> > is simple "everywhere that they would be inclined to pass a function
> > pointer".  If they don't do that then the system won't work for LB.
> > 
> 
> Are you saying that every time I connect to a signal from C, or
> implement a default handler from C, I'd have to pass a GClosure rather
> than a function pointer? 

No!  I am saying where ever function would be passed through an
API in any form other directly it would be by a closure.  Otherwise,
it is pointless as language bindings can't use it.

Think about it this way

  void gtk_signal_connect_object( GtkObject* o, char* n,
                        GtkSignalFunc f, gpointer d)
     {
       g_signal_connect(o,n,g_closure_new(f,d));
     }

In other words nothing changed form most users prospective.

However, if you want to do this 

  struct GtkInfo
     {
       ....
       GtkSignalFunc callback;
       gpointer data;
       ...
     };

This would need to change to 

   struct GtkInfo
     {
       ....
       GClosure callback;
       ...
     };

And you would need to use g_closure_new in the function
creating this (although the user may not even see this.)

Is that more clear?



> That would be a huge mess and would make
> coding in C much more painful. The right way to make language bindings
> first-class citizens is _not_ to make programming in C suck more.

I have no intention of making C API suck.  If you are getting that
impression then it is most likely mistaken.

 
> I don't understand how bindings are even an issue. If there's a way to
> connect a closure to a signal, why should the widget author even need
> to know the difference? Shouldn't gtk_signal_emit take care of the
> details?

Bindings are an issue because anyplace you take a C function 
like the above structure it becomes a mess because the LB can't
store data in the closure (nor in many case be sure the data
will get passed.)

 
> It sounds like your plan will make things a lot more complicated for
> the normal case for C programmers. For 90% of things in C, a function
> and a data pointer is enough. Making language bindings easier is a
> worthy goal, forcing people writing in C to deal with the low-level
> guts of the system is insane however.

Have you seen anything which implied C needs to talk to the guts?


> In fact, gtk+/glib 2.0 seems to be making a lot of things harder
> rather than easier. For example, GObject lacks an easy to use destroy
> notification mechanism (arguments that it's only useful for GUI
> objects are totally unconvincing), and things like GValue and GParam
> make my eyes glaze over with piles of exposed complexity. Tim hasn't
> been that good at explaning the motivation for these changes either.

This is an issue with Tim not myself.  I don't know or understand
the Param stuff.  But closures I see as having very good reasons.


> Let's remember that we must keep the simple things easy and that this
> is even more important than making obscure things possible. After all,
> ease of use from C is a big reason Gtk+ is beating Xt-based toolkits.
> 
> I hope I'm misunderstanding and closures won't really be a concept
> that the average C user needs to deal with at all.

I think you are looking at it from the wrong angle.  

--Karl