W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Future feedback

From: Alex Russell <slightlyoff@google.com>
Date: Mon, 20 May 2013 10:59:01 +0100
Message-ID: <CANr5HFWGZsNfi9zTp22sft3rKXVTXO+Mq-_8iJoaATXqGmSEJA@mail.gmail.com>
To: Sean Hogan <shogun70@westnet.com.au>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, David Bruant <bruant.d@gmail.com>, Jonas Sicking <jonas@sicking.cc>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Rafael Weinstein <rafaelw@google.com>, Adam Klein <adamk@google.com>, Erik Arvidsson <arv@google.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC