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@gmail.com>
Sent: ý4/ý22/ý2013 10:54 AM
To: Dean Landolt<mailto:dean@deanlandolt.com>
Cc: Brendan Eich<mailto:brendan@mozilla.com>; Mark S. Miller<mailto:erights@google.com>; Douglas Crockford<mailto:douglas@crockford.com>; public-script-coord@w3.org<mailto:public-script-coord@w3.org>; Norbert Lindenberg<mailto:w3@norbertlindenberg.com>; Markus Lanthaler<mailto:markus.lanthaler@gmx.net>; es-discuss<mailto:es-discuss@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 }