It implements the emit function for all other functionality it has
this aliased to RestrictedSignal.
A signal is a way to couple components together in a very loose
way. The receiver does not need to know anything about the sender
and the sender does not need to know anything about the
receivers. The sender will just call emit when something happens,
the signal takes care of notifing all interested parties. By using
wrapper delegates/functions, not even the function signature of
sender/receiver need to match. Another consequence of this very
loose coupling is, that a connected object will be freed by the GC
if all references to it are dropped, even if it is still connected
to a signal, the connection will simply be dropped. If this wasn't
the case you'd either end up managing connections by hand, soon
asking yourself why you are using a language with a GC and then
still have to handle the life time of your objects manually or you
don't care which results in memory leaks. If in your application
the connections made by a signal are not that loose you can use
strongConnect(), in this case the GC won't free your object until
it was disconnected from the signal or the signal got itself destroyed.
Full signal implementation.
It implements the emit function for all other functionality it has this aliased to RestrictedSignal.
A signal is a way to couple components together in a very loose way. The receiver does not need to know anything about the sender and the sender does not need to know anything about the receivers. The sender will just call emit when something happens, the signal takes care of notifing all interested parties. By using wrapper delegates/functions, not even the function signature of sender/receiver need to match. Another consequence of this very loose coupling is, that a connected object will be freed by the GC if all references to it are dropped, even if it is still connected to a signal, the connection will simply be dropped. If this wasn't the case you'd either end up managing connections by hand, soon asking yourself why you are using a language with a GC and then still have to handle the life time of your objects manually or you don't care which results in memory leaks. If in your application the connections made by a signal are not that loose you can use strongConnect(), in this case the GC won't free your object until it was disconnected from the signal or the signal got itself destroyed.
This struct is not thread-safe.