From: Braddock (braddock_at_[hidden])
Date: 2007-02-27 20:33:17
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 :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk