- From: Alex Russell <slightlyoff@google.com>
- Date: Fri, 19 Apr 2013 12:57:10 +0100
- To: Ron Buckton <Ron.Buckton@microsoft.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, "Mark S. Miller" <erights@google.com>, es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Markus Lanthaler <markus.lanthaler@gmx.net>, Douglas Crockford <douglas@crockford.com>, Norbert Lindenberg <w3@norbertlindenberg.com>, Luke Hoban <lukeh@microsoft.com>, Tony Ross <tross@microsoft.com>, Adrian Bateman <adrianba@microsoft.com>
- Message-ID: <CANr5HFVpF05-Hv7KaJptzer9+GJZHfQieBDESi2eJMuWfUbFfA@mail.gmail.com>
Hi Ron, Comments inline. On Wed, Apr 17, 2013 at 7:35 PM, Ron Buckton <Ron.Buckton@microsoft.com>wrote: > As someone who has been interested in Promises/Futures in JavaScript for a > number of years, I'd like to throw in my $0.02 regarding a proposed API for > Promises/Futures for thoughts: > > https://gist.github.com/rbuckton/5406451 > > My apologies in advance as the API definitions are written using > TypeScript and not Web IDL. > There's a lot of API in here. If you give the DOMFutures github repo a look, you'll see that we considered some of them: https://github.com/slightlyoff/DOMFuture/ In particular, progress was explicitly written out of the contract of the base class so that subclasses that need it can mix it back in without burdening everyone else with perhaps nonsensical methods. See: https://github.com/slightlyoff/DOMFuture/blob/master/ProgressFuture.idl As for the state variables, we've removed them in the most recent version to avoid potential for "cheating" (as Luke Hoban described it). I'm also not entirely sure I understand why the capability to cancel is being vended to all consumers of a Future. We explicitly disallow that in the current design to prevent the potential for multiple users of a Promise/Future stepping on each other. The thought with the current design is that if you have an interface that needs to vend cancelation, you should at it in a subclass of Future. Your constructor signature looks similar (but not the same) as the one we ended up with, and there appear to be many convenience static methods on Promise. How strongly do you feel about them? >From a design standpoint the only thing that jumps out at me as being very strange is the "synchronous" option for .then() and .done(). What is it meant to do? > -----Original Message----- > From: Anne van Kesteren [mailto:annevk@annevk.nl] > Sent: Wednesday, April 17, 2013 8:46 AM > To: Mark S. Miller > Cc: public-script-coord@w3.org; Norbert Lindenberg; Markus Lanthaler; > Douglas Crockford; es-discuss > Subject: Re: Futures (was: Request for JSON-LD API review) > > > 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. > > > -- > http://annevankesteren.nl/ > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
Received on Friday, 19 April 2013 11:58:08 UTC