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

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 17 Apr 2013 16:46:18 +0100
Message-ID: <CADnb78hV36JtO_zWnZt8EMbWwuzgnimtp7Fs0dJc_odFEDaoHg@mail.gmail.com>
To: "Mark S. Miller" <erights@google.com>
Cc: es-discuss <es-discuss@mozilla.org>, Douglas Crockford <douglas@crockford.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Norbert Lindenberg <w3@norbertlindenberg.com>, Markus Lanthaler <markus.lanthaler@gmx.net>
> On Wed, Apr 17, 2013 at 8:29 AM, Mark S. Miller <erights@google.com> wrote:
>> 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.

I don't find the whole who owns what discussions very interesting to
be honest. If it was up to me JavaScript would just be part of the W3C
and we would not have to deal with that layer of distraction.

In any event, you can take the specification and improve on it
elsewhere if you so desire. It is in the public domain for a reason.
You can also provide technical feedback as to what exactly is evil.
Saying "stop doing this" and implying you're somehow the superior
forum to the other party is not helpful and has certainly not helped
in the past.

Received on Wednesday, 17 April 2013 15:46:46 UTC

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