Re: user_data argument to a signal's class_closure which is a class function pointer member

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-08-20 at 03:01, Mathieu Lacage wrote:
> Le mer 20/08/2003 à 00:33, Tim Janik a écrit :
> 
> [snip]
> 
> > > The reason I came up with this issue is that I find that the use of a
> > > class function pointer as default closure for a signal to be a bit
> > > awkward. This 'conveniant' default forced upon the user by g_signal_new
> > > really turns me mad: I'd be much happier with another 'conveniant'
> > > default which uses a simple function pointer as class_closure.

Like the _gtk_binding_signal_new we are using in GTK+ now for new
binding signals? It would be to have a convenience function in GLib
to do this, but I don't think it would make any sense for
g_signal_new()

Using a fixed function for the class closure *only* makes sense
for the specific case of using signals as named callbacks.

In general, default handlers don't make sense in the class that
adds the signal. If there is stuff that always should be done, do it 
the wrapper function that emits the signal. 

The reason for the class closures as virtual pointers is for classes
that inherit from the class; gtk_entry_button_press_event() and
so forth. This is a pretty huge efficiency and convenience win.

So, I think in order of commonness, what you want is:
 
 A) Class closure as virtual function pointer
 B) No class closure
 C) Class closure as fixed pointer.

Regards,
						Owen