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

Subject: Re: [boost] Interest in non-intrusive signal/slot lib?
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-05-20 18:00:24

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<void*, signal>, 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.