3 ms·
I've read this 3 times and I still can't see what the advantage of this dispatcher is. In the event model, Events that deal with model A also have to be dealt
by rtpg 12y ago
I've read this 3 times and I still can't see what the advantage of this dispatcher is.
In the event model, Events that deal with model A also have to be dealt with in models B,C, and D. Wouldn't this lead to exponential explosion?
The fact that B has to explicitly wait for A in the code also seems prone for errors. If A changes to no longer deal with that event, will B block forever?
And this still builds an event chain, because B is blocking on A. I don't see how this is different from an event chain, execpt that the dependency is non-obvious (whereas a callback chain/future chain will at least show what data is being passed into B from A)
This is maybe OT as well, but this article could really do for some concrete examples in the explanations. "Model A" and "Model B" are not examples.
- DougBTX 12y ago> If A changes to no longer deal with that event, will B block forever? No, A would just no-op, and control will return to B. This is all written in the context of JavaScript, with a synchronous dispatcher and no threads which can block.
- andybak 12y agoIsn't it simply a case of 'spaghetti code' vs 'explicit and clear code'? The dispatcher takes a potential mess of calls between various components, centralizes them and makes the sequence of events and dependencies much easier to reason about.