On Mon, Apr 22, 2013 at 1:53 PM, Kevin Smith <zenparsing@gmail.com> wrote: > > 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? > Perhaps, depending on how all the current libs are being used in the wild. But this assumption does breaks the ducktyping as defined by the spec. Who knows -- this may not be a problem in practice. Alternatively it occurs to me that now that we'll have mutable __proto__ to lean on we could specify something like Promises/A++ as Promises/A+ with the additional constraint that some Promise (or Future, or whatever) builtin exist on the proto chain of any promise. This would allow for instanceof checks to be interoperable across libraries. And really, you don't even really need mutable __proto__ -- this is only necessary for pure-userland interoperability. Since this a standard builtin the problems with Promises/C go away -- even when polyfilled all promise libs could expect to see the same base class. That is, IIRC -- it's been a *long* time since I've really chewed this over. So I guess I'm less skeptical. Promise (and an accompanying Promise.when) could be defined and shimmed into existing tool chains today. A huge chunk of currently working Promises/A+ code would break without a corresponding Promise.prototype.then, but nothing would stop lib authors from adding it. And even without it the migration path would be straightforward and could even be automated. Okay, I'm convinced. But I don't matter -- both TC39 and the Promises/A+ implementers have to be.Received on Monday, 22 April 2013 22:21:27 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:12 UTC