Re: Future feedback

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

I only support adding setImmediate() if it makes Object.observe() more sane.

Received on Monday, 20 May 2013 09:59:28 UTC