- From: David Bruant <bruant.d@gmail.com>
- Date: Thu, 14 Mar 2013 10:48:11 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Anne van Kesteren <annevk@annevk.nl>, www-dom@w3.org, Yehuda Katz <wycats@gmail.com>
Le 13/03/2013 16:47, Jonas Sicking a écrit : > One tricky issue is the exact timing of the call to the .then > function. It would be great if we could enable the resolver function > to do things like call .preventDefault on the event, but that might > require that the .then function is called synchronously which goes > against [1]. I consider that the DOM event model is absurdly broken. Namely, all listeners being called synchronously on .dispatchEvent is a bad idea. I don't think retrofitting Futures into that model is a good idea. Maybe a better idea would be to add a way for event handlers to be .dispatched asynchronously. That would fit in the Future model, but even then I'm not sure it's a good idea. I see Futures as a convenience (or "design pattern" maybe) written on top of events (the general idea of events, not necessarily the ones defined in the DOM). An object having mutually exclusive success/error events where at most one will be fired is pretty common and Futures makes an idiom out of this recurring pattern. But not all events follow this pattern. "readystatechange" is meant to be fired several times, for instance. If people want to make a future out of an upcoming existing event, they can do so in a few lines (as expressed here [1]). Maybe it will be a very common pattern for futures, but it's not certain. Maybe people will use that only for a handful of other events and we'll see a different pattern emerge. I'd be more in favor of shipping minimalistic futures, see how people use them and add hooks to DOM events after having a better understanding of how people use events in combination with Futures, but not before. David [1] https://github.com/slightlyoff/DOMFuture/issues/34#issuecomment-14236676
Received on Thursday, 14 March 2013 09:48:43 UTC