closure summary

[Havoc Pennington <hp redhat com>]

Hi,

Since that thread descended into detail, let me try to summarize the
argument as I see it.

Karl and I agree (I think) that language bindings need only the
functionality from connect_full(), and no more. That is, one destroy
notify.  (And the one invalidate notify is needed for the signal
system, main loop system, etc. internally.) All current bindings
present a pretty nice native-language interface using this
functionality, without especially heinous work on the language binding
implementor's part.

The original rationale for closures was for language bindings. But
that rationale does not extend to multiple destroy notify, multiple
connections, etc. Those features are justified only by their use in C
applications.

Example use cases have included one where you set the callbacks for a
Glade XML object, and another where you have a menu item verb associated
with a GClosure, and you connect the closure to multiple menu items
directly. In both cases there are simple alternative ways to write the
code that work fine. I am therefore still arguing that multiple
connections are not useful.

The other issue is multiple alive objects. The simplest possible use
of these would be:

  struct MyData {
    GtkWidget *w1,*w2;
  };

  GClosure* make_closure(GtkWidget *w1, GtkWidget *w2)
    {
      MyData *d=my_data_new(w1,w2)'
      GClosure *c=g_closure_new(&function,d,&g_closure_free_data);
      g_closure_add_dependency(closure,w1);
      g_closure_add_dependency(closure,w2);
    }

I can't envision any typical app developers using this, or learning
enough to know how to use it. (Potentially the lack of a "destroy"
signal in GObject makes weak references of this kind more
essential. If so, that is likely an argument for the "destroy" signal
more than an argument for weak reference support.)

For me the clinching argument is that the simpler closure API is a
subset of the more complex one; we can implement the complex API
later, retaining backward compatibility with the simpler one, if the
complex API turns out to be needed.

Havoc