Futures

Ron Buckton rbuckton at chronicles.org
Tue Apr 23 11:32:00 PDT 2013


I fall mostly under the "native futures should not implicitly chain library futures" camp. Its easy enough to write:

var p = // some thenable
return new Future(resolver => p.then(resolver.resolve, resolver.reject);

One thing that I find a bit icky is that implicitly attaching to "then" not only is not a guarantee (is it really a "thennable"), but it also leaks a new thenable that may take up more memory and processing time due to possible scheduling of results/errors to the chained (and unused) thenable. It would be slightly better to hook "done" rather than "then". Depending on the various implementations, duck type checking for both "then" and "done" might be slightly more reliable than just looking for "then" and would let us hook "done" to reduce overhead.

If library authors subclass Future, the @class symbol could be easily checked in Future#resolve to chain appropriately, though the Future superclass might need  to be able to construct a new instance of the subclass for calls to Future#then, otherwise you loose the capabilities of the subclass after the first call to Future#then.

Library authors that do not subclass Future could add something like .asFuture() to their prototype (or use a predefined symbol), just as one might to support iterators.

Alternatively, ES might also need to expose a FutureFactory that can be used to create instances of a Future subclass. If that were the case, the Future constructor could take in an optional FutureFactory subclass that is used to construct library subclasses of Future.

Ron

Sent from my Windows Phone
________________________________
From: Kevin Smith<mailto:zenparsing at gmail.com>
Sent: ‎4/‎22/‎2013 10:54 AM
To: Dean Landolt<mailto:dean at deanlandolt.com>
Cc: Brendan Eich<mailto:brendan at mozilla.com>; Mark S. Miller<mailto:erights at google.com>; Douglas Crockford<mailto:douglas at crockford.com>; public-script-coord at w3.org<mailto:public-script-coord at w3.org>; Norbert Lindenberg<mailto:w3 at norbertlindenberg.com>; Markus Lanthaler<mailto:markus.lanthaler at gmx.net>; es-discuss<mailto:es-discuss at mozilla.org>
Subject: Re: Futures


I would love to see this, but best I can tell it can't be a straitforward polyfill. The necessary infrastructure has to settle, and what are Promises/A+ implementers supposed to do in the meantime?

Presumably the standard version of Future would provide some convenient way to get the symbol.  The library would use that to conditionally provide the symbol-named alias.  Something along these lines:

    if (typeof Future !== "undefined")
        MyPromise.prototype[Future.thenSymbol] = MyPromise.prototype.then;

No?

{ Kevin }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130423/02cd0b06/attachment.html>


More information about the es-discuss mailing list