RE: signals versus vfuncs

["muppet" <scott asofyet org>]

Murray Cumming Comneon com said:
>> is this correct?  if so, what's the rationale?  i understand that
>> overriding class closures and calling
>> g_signal_chain_from_overridden is
>> odd and clunky and all that, but having the marshalling
>> metadata around
>> for virtual methods is really important for language bindings!
>
> Maybe you face different problems with perl, but I don't understand the
> problem here. Maybe a specific example of a signal/vfunc would help.

The CellRenderer is a major PITA because there are no signals for the four
vfuncs you need to be able to override.

The problem of binding this to Perl goes like this:

gtk_foo_do_something() emits the do_something signal, which calls the
do_something vfunc as the class closure.

we can't just call a method named "do_something" because we'd get an infinite
loop.  we can't call a method named "DO_SOMETHING", for the obvious
counter-example of GtkObject::destroy mapping to DESTROY, which is reserved
for other uses in Perl.  so, when you create a new subclass, you supply a
function to be used as the class closure override for do_something.  this has
the advantage of not running into namespace problems, because the developer
has complete control over the name of the function used, which may even be
anonymous.  it also means that signals happen completely automatically; we
only have binding work to do when we need to do custom marshalling (e.g., for
naughty signals using G_TYPE_POINTER for argument types).


now, without this machinery for the methods that are to be overridden, how do
we handle vfuncs without signals?  we write a custom marshaller for each
vfunc, and have the developer override on_get_size, on_render, on_activate,
and on_start_editing.  we even have to do other nasty hacks to install those
overrides.


i'm not saying that we can't do anything with them, just that they're a major
PITA for binders and users, because of the inconsistency they introduce, and
the fact that we no longer have the useful metadata to allow the bindings to
do all of this automatically.

and it's not just for gtk2-perl.  pygtk solved the CellRenderer problem by
creating a new subclass from which to derive cell renderers, but you lose the
ability to derive from existing C renderers (a real pain if you want to have a
text renderer, for example).


i'd like to understand the rationale behind not having signals for every vfunc
before i start complaining about it; perhaps there's a really good reason i
hadn't thought of, or perhaps the C developers don't know what the scripting
language developers go through.  <managerspeak> i wanted to start a dialogue.
</managerspeak>  gtk+ is the most binding-friendly widget set i know of, i'd
like it to stay that way.

-- 
muppet <scott at asofyet dot org>