Futures (was: Request for JSON-LD API review)
slightlyoff at google.com
Fri Apr 19 04:57:10 PDT 2013
On Wed, Apr 17, 2013 at 7:35 PM, Ron Buckton <Ron.Buckton at microsoft.com>wrote:
> number of years, I'd like to throw in my $0.02 regarding a proposed API for
> Promises/Futures for thoughts:
> 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:
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:
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 at annevk.nl]
> Sent: Wednesday, April 17, 2013 8:46 AM
> To: Mark S. Miller
> Cc: public-script-coord at 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 at google.com>
> >> 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
> >> 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
> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss