Re: signals versus vfuncs

[Christof Petig <christof petig-baender de>]

muppet schrieb:
> 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.

That's of course different from what gtkmm does. But perl on the other 
hand does not need compile time type security.

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

oh, I see. I don't think that you have any choice (gtk+ does not provide 
vfunc arg specifications at runtime). But you might compile in 
*_vfuncs.def and use that.

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

Why not make it the default (as gtkmm does) and create a quick path for 
non-perl-side derived types.

   Christof