RE: signals versus vfuncs

["muppet" <scott asofyet org>]

Murray Cumming Comneon com said:
>muppet said:
>> overriding existing vfuncs means you have to have the struct
>> offsets someplace, and you have to know how to marshall them.
>>  with all that, you either need a database of vfuncs and
>> parameter types,
>
> We have hand-written *_vfuncs.defs files. And we have code to generate
> *_signals.defs files.

our signal marshallers are all magical and automatic -- there's one generic
marshaller for GClosures, and overrides may be specified at boot time.  not as
fast as your custom generated code, probably, but the maintenance and code
size are almost zero, and that's a huge benefit.  if a new version of gtk+
adds a signal, it Just Works, with new no support code needed.

i suppose we could install marshalling data for vfuncs in a GType's qdata, but
that starts to get expensive for startup time and memory usage...  and we'd
still have to generate the data somehow at compile time because the library
doesn't provide it.  hence, we've gone with hand-coded marshallers for vfuncs
-- painful, but the lesser of evils.


> Hmm, maybe you're doing this anyway and I'm not helping.

indeed, this is all helpful.  i'm getting ideas about combining the defs for
vfuncs with other techniques.  i'm sorry to spam the gtk developers with all
of this bindings-related stuff, but it can't hurt for them to see what we go
through to use their code.  :-)


> I don't know the perl details, but I really feel that it should be possible
> if you override the vfunc in a C Gtype.

that's what the "__PACKAGE__->install_overrides" hack does.  i'm just unhappy
that it has to be manual.


-- 
muppet <scott at asofyet dot org>