Futures (was: Request for JSON-LD API review)
allen at wirfs-brock.com
Fri Apr 26 09:45:31 PDT 2013
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.
> 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> wrote:
> On Wed, Apr 24, 2013 at 10:51 AM, Domenic Denicola
> <domenic at domenicdenicola.com> wrote:
> > From: Andreas Rossberg [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]
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss