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

[Tim Janik <timj gtk org>]

META: please don't set Reply-To: headers if the message in question
      is an ordinary non-crosposted list message.

On 19 Aug 2003, Mathieu Lacage wrote:

> Hi Tim,

> > that functions prototype is:
> >
> > GClosure* g_signal_type_cclosure_new            (GType          itype,
> >                                                  guint          struct_offset);
> >
> > > Here, the itype argument to the g_closure_new_simple function is indeed
> > > an arbitrary value for the user_data argument of my signal's default
> > > handler.
> >
> > the above prototype should give you a hint, that the class type and
> > the function pointer offset are essential to call a specific virtual
> > function of a specific class. naturally, those two data items will
> > have to be stored somewhere, and the code snippet you posted above
> > shows how the itype is being stored in the resulting closure.
> > (for those curious, the struct_offset is stored together with
> > a seperate marshaller that needs to be installed for class function
> > closures).
> >
> > > So, the question is: is this special value part of the
> > > officially exported API ?
> >
> > no it is not. the "official API" doesn't provide you with a user_data
> > argument to class functions if you use the *convenience* interface
> > g_signal_new(). do you have any good reasons to change that and can
> > present reasonable use cases for user_data with class functions?
>
> I do not have any reasonable use case for this. I am merely curious.
>
> 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.

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

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

> My biggest gripe is that
> the resulting code is a bit unreadable and the speed/memory savings
> maybe useless. Maybe I am wrong.

i don't quite see what unecessary speed or memory saving you
mean to point out. can you be more specific please?

> thanks for your long answer,
>
> Mathieu
> --
> Mathieu Lacage <mathieu gnu org>
>

---
ciaoTJ