Re: simplifying closures

[Maciej Stachowiak <mjs eazel com>]

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? 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 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?

> > Also, the GClosure object and API seem low level and difficult to
> > understand if it's supposed to be an end-programmer API. Invalidity
> > notification vs. destroy notification, adding multiple data by
> > creating a derived struct, etc. is pretty intimidating stuff.  People
> > don't understand the existing signal_connect() variants.
> 
> This is a reasonably good argument, but will apply no mater how
> many notifications or destroy functions we allow.  Tim has sucessful
> argued to me there must be 2 types and I think his reasoning is sound. 
> Thus the any functioning closure API must have that.  If the C
> widget writter must know how to deal with closures to make good
> LB workable code, the API must be explainable in a short tutorial
> and must make sense.  To the average library users connections are 
> largely balck box though so just telling them these functions make 
> closures which are "function objects" which you can pass and be called 
> back later is more that enough.
> 

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.

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.

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.

 - Maciej