Re: [boost] Interest in non-intrusive signal/slot lib?

On 5/20/2015 11:32 AM, Peter Dimov wrote:

Edward Diener wrote:

...

This is similar to the way in the signals2 library that one has to have access to a boost::signals2::signal in order to setup a connection to a slot. So while I like your library I do not immediately understand the advantage it has over signals2.

When you already have an existing third-party object (say, XButton) it's more convenient to not have to think where to place the corresponding signal object. Non-intrusive dispatch is kind of like the library containing the equivalent of map, automatically managing the signal objects corresponding to an external, third-party, object.

I understand that with Synapse you are merely making a call at a convenient point in order to emit a signal, whereas with signals2 you need to have a boost::signals2::signal object somewhere for the particular signal triggering before you can emit a signal or have connections to handle the signal. But in Synapse you also must have a signal emitter which is accesible for the event handlers making the connection to the event. This to me is equivalent to boost::signals2 having a signal object.

In the use case in which you define your buttons, there's not much to gain, you make them contain your signal objects. But third-party buttons don't contain your signal objects, they contain their own functionality for notifying you of events, sometimes that's (their own) signal implementation, sometimes a callback/std::function, sometimes you need to override a virtual method, sometimes they send you messages. With a non-intrusive signal library, you just attach an emit call to the third-party notification mechanism and the rest of the code can connect to the non-intrusive signal. This avoids the need to wrap the external objects in your own types that contain signal objects.

The rest of the code can connect to the non-intrusive signal as long as it has access to the signal emitter. It is not as if when the signal emitter goes out of scope you can make a connection to that signal anymore. Or have I misunderstood this ? In both cases whatever is emitting the signal has to be accessible. I do understand that conceptually in Synapse have the signal emission be disconnected from the signal connection appears a less dependent design but this seems to me to be only on the surface. This does not mean I do not like Synapse. Its syntax for emitting a signal from any object is clearer than signals2, but under the surface the separation between the signal and signal handler seems much the same.