On Friday, May 17, 2013, Sean Hogan wrote: > On 17/05/13 12:03 PM, Boris Zbarsky wrote: > >> On 5/16/13 6:52 PM, Sean Hogan wrote: >> >>> So what would be the problem if `setImmediate()` just appended to the >>> futures task source? >>> >> >> None per se, except to the extent that you want to have different >> priority settings for setImmediate and futures or to the extent that you >> want some sort of ordering guarantees between setImmediate and something >> other than futures. >> >> > > From what I've read, the main demand for `setImmediate` (or equivalent) is > for JS implementations of Promises, etc. Would anyone care if > `setImmediate` was implemented and then Futures (or whatever browsers > settle on) got the same task source? > I don't know of any reason why setImmediate is required for Futures/Promises. The most important contract is that resolution/callbacks are provided *apparently* outside of synchronous control flow. That is to say, if I .resolve() or .then(), the next line should not be able to observe side-effects from side-effect generating callbacks. That contract can be filled by any of end-of-microtask (Mutation Observers use this today), setTimeout() (a full turn around the event loop with clamping), or never-delivered. I only support adding setImmediate() if it makes Object.observe() more sane.
Received on Monday, 20 May 2013 09:59:28 UTC