On Apr 24, 2013, at 9:17 PM, Ron Buckton wrote: > 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.
Note that ES 6 will fully support subclassing of built-ins constructors. Instances of built-ins are branded and subclasses instances are expected to be branded the same as the original built-in superclass instances. Inheritable built-in prototype methods, when appropriate, are specified as doing a brand check. The actual branding mechanism used for built-ins is not observable and hence is left as an implementation detail. The mechanism is required to work across frames. The new operator protocol in ES6 is enhanced to ensure that subclass instances are branded appropriately. However, there is a technique that can be used to accomplish essentially the same thing in any current JS implementation that supports __proto__. For an overview of ES6 support for subclassing built-ins see http://wiki.ecmascript.org/lib/exe/fetch.php?id=meetings%3Ameeting_jan_29_2013&cache=cache&media=meetings:subclassing_builtins.pdf For the backwards compatibility hack that accomplishes the same thing see slide 16. Allen > > From: [email protected] [mailto:[email protected]] > 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. <[email protected]> wrote: > On Wed, Apr 24, 2013 at 10:51 AM, Domenic Denicola > <[email protected]> wrote: > > From: Andreas Rossberg [[email protected]] > >> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
