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

Re: Futures (was: Request for JSON-LD API review)

From: Mark S. Miller <erights@google.com>
Date: Wed, 17 Apr 2013 08:31:17 -0700
Message-ID: <CABHxS9jS6NvvSBKFBzjVfCHpku5LbD6Uxcn13Gf0jTD_LqWR0Q@mail.gmail.com>
To: es-discuss <es-discuss@mozilla.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Markus Lanthaler <markus.lanthaler@gmx.net>, "public-script-coord@w3.org" <public-script-coord@w3.org>, public-rdf-comments@w3.org, Douglas Crockford <douglas@crockford.com>, Norbert Lindenberg <w3@norbertlindenberg.com>

On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller <erights@google.com> wrote:

> Frankly, DOMFutures have nothing to do with the DOM, other than the fact
> that the DOM would benefit from using them -- as would many other APIs.
> There is nothing browser specific about this, and much that is JavaScript
> specific. There is no reason for this to be under the jurisdiction of the
> w3c. There is already a promise strawman cooking for ES7 at
> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency . More
> recently, the discussions for settling the promise spec have moved to
> https://github.com/promises-aplus/promises-spec/issues?state=open . When
> DOMFutures began, it was incompatible with promises in annoying ways.
> Fortunately, through much good work by Alex on the DOMFutures side and many
> people on the promises side, DOMFutures is now mostly compatible with
> Promises/A+. I respect the work Alex has done on this. But it is still
> proceeding within the wrong organization.
> The main argument I've heard for proceeding with w3c/DOMFutures rather
> than tc39/promises is that the DOM can't wait for tc39 to get around to
> standardizing promises in ES7. But we should have our eyes open to the
> consequences. As Crockford says (paraphrasing Knuth) "Premature
> standardization is the root of all evil." The likely result of DOMFuture
> proceeding in this way is that it will be wrong, ES7 will be stuck with it
> and mostly unable to fix it, and we will all be stuck with the consequences
> for a very very long time.
> As with Object.observe, if the need for promises is that urgent, it needs
> to be on an accelerated track with the JavaScript context -- as it already
> de facto is at promises/A+. It should not be needlessly tied to the browser
> or to w3c.
> On Wed, Apr 17, 2013 at 7:24 AM, Norbert Lindenberg <
> w3@norbertlindenberg.com> wrote:
>> On Apr 16, 2013, at 16:55 , Tab Atkins Jr. wrote:
>> > On Tue, Apr 16, 2013 at 8:30 AM, Markus Lanthaler
>> > <markus.lanthaler@gmx.net> wrote:
>> >> After a short discussion with Robin we decided to use method
>> overloading to
>> >> We also considered Futures but decided that introducing a normative
>> >> dependency to the DOM spec is not acceptable at this stage.
>> > In this case, your API is a textbook example of Futures.  You have an
>> > async call which returns a single value, or an error.  You can't get
>> > much more perfect than that.
>> Maybe Futures should be in a separate spec? They don't seem to have any
>> dependencies on DOM, and having them separate would reduce the bureaucratic
>> hurdles for non-DOM specs to refer to them. Maybe eventually they could
>> migrate into the ECMAScript standard library (currently known as ES chapter
>> 15).
>> Norbert
> --
>     Cheers,
>     --MarkM

Received on Wednesday, 17 April 2013 15:31:44 UTC

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