Re: [boost] [synapse] Review

Subject: Re: [boost] [synapse] Review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-12-13 21:46:27

On Tue, Dec 13, 2016 at 5:38 PM, David Sankel <camior_at_[hidden]> wrote:

> On Tue, Dec 13, 2016 at 4:26 AM, Gonzalo BG <gonzalobg88_at_[hidden]> 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-December-2-td4690209i20.html#a4690264
.

Thanks,
Emil