Re: signals versus vfuncs

[Tim Janik <timj gtk org>]

On Fri, 9 Jan 2004, Christof Petig wrote:

> Ross McFarland schrieb:
> > that's the main problem. without signals we have to add specific
> > code/info for each and every situation. with signals it's all magic
> > (provided that they're done right and have the correct parameter types.)
> > we (and by we i mean muppet) have purposed (and even somewhat
> > implemented) solutions for the situation, but they are at best hacks
> > that don't have really to be, if there were signals for us to connect to
> > as most older code seems to have done. bascially i think muppet is
> > looking for 'the reason' why there seems to have been a shift in the way
> > things where done, and to say that it makes bindings much harder to do
> > and error prone.
>
> Didn't I say that vfuncs are much much much faster (nearly no overhead)
> and always call exactly one 'callback', so they can return any type of
> result. This is impossible with signals (having 0-N subscribers).

signals are good prepared to handle any type of return value, that's
by means of implementing signal accumulators. they can decide whether
to abort a signal emission based on a return value and they also
get to decide how to combine/choose the returned value out of the
possible N.
but you're right, in that that's no where as fast as a vfunc call.

> That's the reason for vfuncs. I expect a 2-5x slowdown for TreeViews if
> vfuncs are replaced by signals (guessed out of thin air). Unacceptable.
>
> I'm no core gtk developer, so I might guess their intentions wrong.
>     Christof
>

---
ciaoTJ