Futures (was: Request for JSON-LD API review)

Ron Buckton rbuckton at chronicles.org
Wed Apr 24 12:17:31 PDT 2013


Be it Promise or Future, instanceof won't work across frames. It would likely still require a Future.isFuture/Promise.isPromise just as we need to have Array.isArray now. That is, of course, unless we can use symbols for branding in a fashion that library authors could use without forking their library for pre- and post- ES6 (or later) versions.

From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Dean Landolt
Sent: Wednesday, April 24, 2013 12:09 PM
To: Tab Atkins Jr.
Cc: Mark S. Miller; es-discuss
Subject: Re: Futures (was: Request for JSON-LD API review)



On Wed, Apr 24, 2013 at 2:18 PM, Tab Atkins Jr. <jackalmage at gmail.com<mailto:jackalmage at gmail.com>> wrote:
On Wed, Apr 24, 2013 at 10:51 AM, Domenic Denicola
<domenic at domenicdenicola.com<mailto:domenic at domenicdenicola.com>> wrote:
> From: Andreas Rossberg [rossberg at google.com<mailto:rossberg at google.com>]
>> Mark, could you summarize the rationale for this, or provide a more specific link to the appropriate bit of the discussion you are referring to?
>
> I'm not Mark, and he might have something more specific in mind, but this summary was pretty helpful:
>
> https://gist.github.com/ForbesLindesay/5392612
These aren't very good reasons, unfortunately.  :/

The JQP... problem can be solved by a single "flatten" operation added
to the API.  This is a totally reasonable operation, same as it would
be for Arrays.


I'll do you one better and suggest the JQP... problem can go away completely the day TC39 decides on a built-in -- let's call it `Promise` for the sake of argument. A new spec, call it Promises/A++, could then be defined which states that this class is to be included in the proto chain of compatible promises. For the sake of interoperable shimming libraries should create this global if it doesn't exist (this part's a little sketchy but I can't think of a good alternative that doesn't involve abusing __proto__).

Now, instead of a ducktest for a `then` method the promise check would instead be specified as `instanceof Promise`. For the sake of backward compatibility libraries can choose to add a Promise.prototype.then so that these new promises work with old promise libs too. If it comes comes to it, old promises can be made to work in the new regime with a little __proto__ hacking.

The only reason thenables won is because library authors didn't have a formal namespace to hang these things. This is what ultimately made assimilation necessary, and it's a non-issue as soon as TC39 specifies a Promise base class.
[snipped the rest, but FWIW I totally agree w/ Tab]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130424/59511b19/attachment.html>


More information about the es-discuss mailing list