Re: [boost] Synapse library review starts today December 2

Subject: Re: [boost] Synapse library review starts today December 2
From: Robert McInnis (r_mcinnis_at_[hidden])
Date: 2016-12-04 17:51:05

-----Original Message-----
From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Emil
Dotchevski
Sent: Sunday, December 04, 2016 5:45 AM
To: boost_at_[hidden]
Subject: Re: [boost] Synapse library review starts today December 2

Emil said:
> 
> >      - What is your evaluation of the potential usefulness of the
> >>        library?
> >>
> > I don't think it's that useful, but I guess I would still use
> > boost.signals2 and boost::asio::io_service for interthread signaling. 
> > I'm not convinced this should be a distinct library, and not a feature 
> > of boost.signals2.
> >
>
> Synapse does not claim to be a "better" Signals2; its usefulness is not as
an alternative 
> to Signals2 but as a solution to problems Signals2 cannot solve. Here are
three examples 
> of this, though I have many more:
>
>
http://zajo.github.io/boost-synapse/handling_events_from_an_OS_message_pump.
html
>
http://zajo.github.io/boost-synapse/adding_custom_signals_to_Qt_objects_with
out_MOCing.html
>
http://zajo.github.io/boost-synapse/using_meta_signals_to_connect_to_a_C-sty
le_callback_API.html

I disagree with this design style, which is to say I also disagree with the
existing slot/signal style.

As an example, what if we had a system with hundreds of thousands of
numerics... each with a particular 
name.  Then imagine a rule set that had to maintain integrity as any
particular numeric were to be 
changed.  With slots or synapses, you're forced to search for the object
each time before applying the
rules.  This would bog down quickly as the number of updates per second
increased (imagine 100k objects 
and 2-10k entwined rules being updated 2k times per second.  That's a real
world scenario) 

Objects should have events they can trigger or subjects they contain/manage
which would trigger
given a certain situation (value changes, particular event arrives, flag
flips, whatever) and the
observer(s), being unknown to the original object, would observe the event
via a loose coupling 
mechanism.  

This allows for a system to have hundreds or thousands of objects all
trigging events at random but
only notifying the particular observers that are interested in that
instance's event.

This allows for a more flexible system while promoting dependency driven
updates... which would
result in the best performance for an event notification system.

I've been using such a design since 1990 and posted a rendition of it to
this group 3 months ago:

https://github.com/tiny/boost_observers

Regarding the real world scenario mentioned above, please check:

https://github.com/tiny/boost_observers/blob/master/test/simple_numerics.cpp
and
https://github.com/tiny/boost_observers/blob/master/test/stockportfolio_nume
rics.cpp