Re: signals versus vfuncs

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

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]