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

[Mathieu Lacage <mathieu_lacage myrealbox com>]

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.
> 
> how is that different from an ordinary signal connection? or simply
> supplying a class closure for signal_new?
> also, you fail to realize that the extra indirection where a
> funciton pointer is read from the class isn't there as an anoyance, but
> to allow virtualization of methods, i.e. derived classes can override
> a parent class' implementation of a specific function.

I do understand that. However, I think 90% users do not need this. As
such, it adds:
  - extra class functions pointers exported to the user through the
header file
  - extra weird stuff to the author who does not even know why his
class_closures are class function pointers.

Do you think I am wrong here in the 90% guess ? This guess is based on
the fact that almost none of the people I asked this to (mainly #gnome
and #gtk+ irc members) could tell me why their class_closures were class
function pointers. 

I could probably do some code analysis in GTK+ and Gnome to get a hard
number if you feel this is worth it.

> 
> > Given
> > this, I tried to use the other functions but their use is a bit
> > cumbersome and, as shown in this mail, really dangerous since the exact
> > semantics are not that trivial.
> 
> i fail to see where semantics are explained to be dangerous in
> your previous message. if you supply a normal closure as class
> handler, there's no user_data being set on it, and if you supply
> just a function pointer location without user_data (i.e. what
> the g_signal_new() signature allowes you), there's obviously no
> user_data to access.

Yes. The 'dangerous' adjective is not really exact. Trying to explain
why I fell in the trap of this user_data parameter would be a bit long.

However, I would like to point out that this class_closure is the only
place in all of GObject where a 'callback' does not have a user_data
parameter and I doubt 90% users could tell you out-of-the-box if and why
there is supposedly a user_data parameter to the class_closure when it
is a class function pointer (again, this number is a guess based on the
fact almost none of the people I talked to about this issue could come
up with a meaningful reason as to why their class_closures were class
function pointers) .

> 
> > > > If not, would it be possible to set it to zero
> > > > (or something like 0xdeadbeef) instead ?
> > >
> > > yes, pretty easily. at the cost of enlarging class closures by
> > > sizeof(GType), since i need to store the type somewhere else, if
> > > user_data is going to be 0xdeadbeef.
> > > i'm afraid, people will be right though, if they *then*
> > > claim user_data to contain some "arbitrary" value ;)
> >
> > Obviously, yes. :) The goal of my question is not really to know whether
> > the change is technically feasible but to know if you would consider it
> > reasonable.
> 
> i'm sorry, i fail to be able to tell you whether a change is reasonable
> without consideration of a valid usage case.
> 
> > I have very epidermic reactions to this kind of 'optimizations' which
> > are scattered everyhwhere in GSignal and GType.
> 
> what "optimization" are you talking about here?

The one you describe just above: you store a GType in a field which has
nothing to do with a GType to save creating another field which would be
used to store this GType. I know that the code and the cast are safe but
I question the usefulness of such space savings: when I read the code in
GClosure and GSignal, it took me 'a bit' of time to figure out what was
happening.

regards,
Mathieu
-- 
Mathieu Lacage <mathieu gnu org>