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

Subject: Re: [boost] Interest in non-intrusive signal/slot lib?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2015-05-20 19:13:08

On Wed, May 20, 2015 at 3:00 PM, Edward Diener <eldiener_at_[hidden]>
wrote:

> 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 ?
>

No, you got that right.

> In both cases whatever is emitting the signal has to be accessible.

On the surface that's not a big deal but typically the code that is
emitting the signal already has an object that it did something to, or
received a notification from. If emitting the signal requires another
emitter object then in addition it must have access to that too -- which
sometimes is problematic, not just inconvenient.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode