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

Subject: Re: [boost] Synapse library review starts today December 2
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-12-05 21:13:30

On Mon, Dec 5, 2016 at 9:31 AM, Nat Goodspeed <nat_at_[hidden]> wrote:

> I think what confused me about the Synapse documentation was the use
> of the term "emitter," which suggests a locally-stored signal
> instance.

I suppose that makes sense to a Signals2 user because in its design the
signal object does the emitting, but the term "emitter" would make perfect
sense to people who have experience with other signal programming
libraries, for example Qt. I added a new documentation page in an attempt
to clarify and highlight the differences in design between Synapse and
Signals2, since it seems like many readers wonder what I might think is
wrong with Signals2 (the answer is nothing, it's just different):
http://zajo.github.io/boost-synapse/Comparison_between_Boost_Signals2_and_Synapse.html
.

> In one of our applications, we use an "event" framework in which
> senders and receivers are loosely coupled. Any given sender and
> receiver can communicate, regardless of the relative order in which
> they are constructed, by consulting a central map with find-or-create
> semantics. They need only agree on the map key. In other words, I
> believe that application has use cases of the kind that Synapse
> intends to address.
>

Yes, it is possible to use Signals2 in a specific case like this, to
achieve what Synapse does in the general case non-intrusively (any object
whatsoever can be passed as an emitter to emit<>). With Synapse, that
central map would be replaced by emit<S>(e), where "e" would be the address
of either the "sender" or the "receiver", or even of some other object
known to both -- whichever makes sense to use as the Synapse emitter.

> (But the connection need only be made once for each receiver -- the
> search isn't performed all over again on every event. I expect the
> same is true for proper use of Synapse.)
>

Nope, Synapse must do the search every time emit is called, though it is
limited only to connections of the specified signal type (in Synapse,
signals are types). That is the price of it being non-intrusive, however do
note that the search can be done in O(1) using hashing.

> So for me the term "rendezvous point" makes more sense than "emitter."
>
> To me the Synapse library looks like this:
>
> * front-end API based on a central map of rendezvous points
> * back-end implementation of rendezvous points that essentially
> duplicates Boost.Signals2, with some features omitted (as in the
> critiques earlier in this thread)
>
> Our map's mapped_type is (a thin class wrapped around)
> boost::signals2::signal. So while I understand the value of having a
> central map of rendezvous points, I do not understand why you would
> use anything other than Boost.Signals2 on the back end.
>

Please see my response to Klemens Morgenstern.

Thanks,
Emil