Re: [boost] interest in a "signal flow" library?

From: Michael Marcin <mike@mikemarcin.com>
These operator overloads for connecting multiple signals seem too cutesy and confusing. How often do these long chains of signals get connected together? I would imagine at most a dozen such chains for a complex application but maybe I'm wrong. Braddock brings up good points and I find his imagePipeline function much easier to read (it will also almost certainly be easier to debug and to mentally assure myself of correctness).
In the applications I'm currently working with there really aren't that many chains/pipelines and they really aren't that big (several to about a dozen). The whole signal mechanism involves a little hit on efficiency, so it probably shouldn't be used to connect the smallest components of the code. I found the greatest benefit of this mechanism after getting used to the syntax and developing a few components that used it. It became really easy to prototype applications and whip up new things from existing components in no time. The whole mentality of using signals and slots encourages development of components that are more concerned about the data than where they are getting the data from (and although good C++ practices should probably focus on the same I know that's not always the case at least for me). When you combine this with the ability to easily interconnect components (through simple syntax), it gives nice benefits. I definitelly agree with you regarding debugging - debugging with signals can be a bit of a pain :-) Stjepan
participants (1)
-
Stjepan Rajko