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-boun...@mozilla.org [mailto:es-discuss-boun...@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. <jackalm...@gmail.com<mailto:jackalm...@gmail.com>> wrote: On Wed, Apr 24, 2013 at 10:51 AM, Domenic Denicola <dome...@domenicdenicola.com<mailto:dome...@domenicdenicola.com>> wrote: > From: Andreas Rossberg [rossb...@google.com<mailto:rossb...@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]
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
