On 5/12/2016 11:51, Robert McInnis wrote:
I disagree with this design style, which is to say I also disagree with the existing slot/signal style.
As an example, what if we had a system with hundreds of thousands of numerics... each with a particular name. Then imagine a rule set that had to maintain integrity as any particular numeric were to be changed. With slots or synapses, you're forced to search for the object each time before applying the rules. This would bog down quickly as the number of updates per second increased (imagine 100k objects and 2-10k entwined rules being updated 2k times per second. That's a real world scenario)
The slot/signal model is the same as the observer model, it's just that your observers happen to implement one signal "changed" on all objects instead of defining different signals for different purposes. Instance-based signals like you're talking about are what Signals2 does. It has the benefit of callbacks being stored locally, at the cost of being intrusive (the object raising the signal needs to contain the signal instance). This library takes the other approach of being non-intrusive and storing the signal implementations elsewhere -- the benefit is that you can have objects emit signals on behalf of other objects that don't need to know that the signalling framework exists, but comes with some performance costs as a result. Some use cases would naturally lend itself to one, while others would lend itself to the other. If all of the code is controlled by you then using Signals2 probably makes more sense, since it's trivial to include the signals in your own classes and it gives you better performance (in theory -- YMMV with mutexes). But Klemens is asserting that there are some cases where the alternate design is more useful; while I can't think of any such cases I've personally encountered, I have little doubt that they could exist and as such a library that supports it could be useful.