Tue, 27 Feb 2007 11:39:49 -0700, Stjepan Rajko wrote:

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

I have had a similar revelation working on my similar data flow framework, combined with heavy use of boost::function and boost::bind. I find my programming is now FAR more functionally oriented. Step one of getting anything done is to produce a function that takes x as input and produces y as output. I can then queue that function, schedule that function, trigger that function on a signal, etc, etc. Feels downright lispy...and very powerful. However, adopting a functional style is one thing. But creating a new syntax which constrains you to that style, appears less expressive than the C++ language itself, and will undoubtedly be more difficult to maintain, is an act that requires considerable justification. I would have a legitimate need for your syntax if, for example, the different functions executed in parallel threads, or were queued to specific worker threads, if I could somehow otherwise control and schedule the execution of the invoked functions, or traverse the call graph. This could bring it closer to a "pipes and filters", LabView, or Petri Net design, but all are very different than straight signal wiring of serial processes.

I definitelly agree with you regarding debugging - debugging with signals can be a bit of a pain :-)

-braddock