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

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

        -braddock