More on SigSlot
More about SigSlot:
I've been emailed by a couple of people pointing out to me that the DOM's addEventListener does pretty much the same thing, and this is in part true. If you are dealing only with DOM nodes and care only about pre-defined events that can be generated by them, then addEventListner is the clear winner.
Making the adoption of SigSlot in JS even more difficult, I haven't been able to figure out how to "intercept" the calls of functions in JS (and I'm beginning to think that it's really not possible), and so any SigSlot library in JS will require some alternate means of calling signal functions.
In the case of the NW SigSlot library, it's handled with the sig.emit() method. To emit the signal registered on object foo's bar method, you might have to do the following:
sig.emit(foo.bar, argument1, argument2);
It's not elegant, but it works. C++ implementations of SigSlot (of which there are a few) are able to side-step this problem by using functors (maleable function objects) and/or pre-compilers. Neither of which is available in JS.
So why would I ever choose this over addEventListner? Well, because it's not tied to DOM nodes or DOM events. For instance, consider the following situation:
You have a complex client-side app, multiple form fields depend on each other and you poll the server for updates to some peice of data. Some portions of your data display are derived from values in other portions of the client-side application. So how do you make sure the right objects get updated?
The answer that you'll get 9 times out of 10 includes some monolithic "update" function that knows about all the fields that need to be updated. This is all well and good, but it can turn into a maintenience nightmare very quickly, espcially if the client gets to choose which fields they care about (you know, a useful application). Using signals and slots, you can create an object for each field which has an "update" method that updates ONLY it's value and takes a single input (the value it derives from). Using signals and slots it's possible to chain these objects togeather without each of these object having to know how (or event that) it's value is connected to some other form element's. It simply receives an update signal from the slot that it got registered to.
This is an admittedly simple example, and the value of SigSlot here is marginal, but it's very simple to think up situations where providing dynamic updates to end users can be made a much saner thing to do because of the maintainability gained by decoupling the caller from the called.