- From: Mark S. Miller <erights@google.com>
- Date: Wed, 17 Apr 2013 08:31:17 -0700
- 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>
- Message-ID: <CABHxS9jS6NvvSBKFBzjVfCHpku5LbD6Uxcn13Gf0jTD_LqWR0Q@mail.gmail.com>
[+es-discuss] 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 > -- Cheers, --MarkM
Received on Wednesday, 17 April 2013 15:31:49 UTC