Re: [boost] [synapse] Review

On Tue, Dec 13, 2016 at 5:38 PM, David Sankel wrote:

On Tue, Dec 13, 2016 at 4:26 AM, Gonzalo BG wrote:

...

David Sankel wrote:

...

or if we had an suite of different variant types with different tradeoffs

Recently Boost.Hana was accepted into Boost, with its own tuple type, such that we now have boost::tuple, boost::fusion::tuple, std::tuple, and boost::hana::tuple...

I don't think this is a good situation! Hana had other merits that compensated for the drawback of introducing another tuple type. Many organizations avoid Boost for unfortunate situations just like this.

I can't tell if this is a good "situation" without studying each of the boost tuple types. On the face of it, I have to assume that there are good reasons for the different types (this is off-topic, but sometimes even avoiding a dependency on another (large) library is a good reason, especially if each library can use "foreign" tuple types generically.)

So while I agree that having 4 types to do the same thing can be bad, I

...

would really like to hear why do you think that: - Boost.Signals2 signal type chose the right trade-offs,

In sum, I think the Boost.Signals2 model is easier to understand and use for the common case. They work a lot like function pointers, which are familiar, and the storage model is straightforward to explain.

I agree, Signals2 is a good library.

- the trade-offs chosen by Synapse's signal type are not worth the "cost"

...

of having two different signal types in Boost.

I didn't find a strong motivation for having another signals library with this design in the documentation nor could I come up with it on my own. I could be convinced that we really need this with some compelling motivation though notwithstanding the interface issue I raised.

Synapse can do things that Signals2 can't, at a cost. Specifically, it can use any user-defined object of any user-defined type as an emitter. In this discussion we already explored the idea of extending Signals2, or even using Signals2 as a back-end for Synapse, rather than introducing a new library, see http://boost.2283326.n4.nabble.com/Synapse-library-review-starts-today-Decem... . Thanks, Emil