domenic at domenicdenicola.com (2014-02-24T21:10:45.781Z)
On Tue, Feb 18, 2014 at 11:12 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > Just to be clear, you're saying that the above would work in ES5 with a polyfill implementation of Promise. Right? Yes, it works in the current git HEAD of `es6-shim`. There are some checks to ensure that `SubPromise` inherits from `Promise`, which would also ensure that `@@create` is inherited (in the future). (See https://github.com/paulmillr/es6-shim/pull/218 for the grungy details.) > It wouldn't work in an implementation where Promise was natively implemented according to the ES6 Promise spec but where 'new SubPromise(exec)' did not include a call to SubPromise.@@create. According to the ES6 spec, `new SubPromise(exec)` should include a call to `SubPromise.@@create`, right? As I read the spec, `new SubPromise(exec)` invokes `SubPromise.[[Constructor]](exec)` which would then invoke `Construct(SubPromise, [exec])`. In turn that would invoke `CreateFromConstructor(SubPromise)` which would fetch `SubPromise.@@create` which gets the inherited `Promise.@@create` and so would invoke `AllocatePromise(SubPromise)` to create the required `[[PromiseStatus]]` and other internal slots. So the code above would work in a fully-compliant ES6 implementation. The question is: what should it do in the weird "not quite ES6, but more than ES5" implementations that are shipping today. This isn't an ES6 spec issue, it's a challenge to implementors to provide forward-compatibility.
[resending to list, original was sent from wrong address and got bounced] On Tue, Feb 18, 2014 at 11:12 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > On Feb 18, 2014, at 12:44 PM, C. Scott Ananian wrote: >> ```js >> var SubPromise = function(exec) { Promise.call(this, exec); ... }; >> Object.setPrototypeOf(SubPromise, Promise); >> SubPromise.prototype = Object.create(Promise.prototype); >> SubPromise.prototype.constructor = SubPromise; >> ``` >> Note that `SubPromise` inherits `Promise.@@create` and so this code >> will work fine in an ES6 environment. (Blame @domenic, he showed me >> that this should work!) > > Just to be clear, you're saying that the above would work in ES5 with a polyfill implementation of Promise. Right? Yes, it works in the current git HEAD of `es6-shim`. There are some checks to ensure that `SubPromise` inherits from `Promise`, which would also ensure that `@@create` is inherited (in the future). (See https://github.com/paulmillr/es6-shim/pull/218 for the grungy details.) > It wouldn't work in an implementation where Promise was natively implemented according to the ES6 Promise spec but where 'new SubPromise(exec)' did not include a call to SubPromise.@@create. According to the ES6 spec, `new SubPromise(exec)` should include a call to `SubPromise.@@create`, right? As I read the spec, `new SubPromise(exec)` invokes `SubPromise.[[Constructor]](exec)` which would then invoke `Construct(SubPromise, [exec])`. In turn that would invoke `CreateFromConstructor(SubPromise)` which would fetch `SubPromise.@@create` which gets the inherited `Promise.@@create` and so would invoke `AllocatePromise(SubPromise)` to create the required `[[PromiseStatus]]` and other internal slots. So the code above would work in a fully-compliant ES6 implementation. The question is: what should it do in the weird "not quite ES6, but more than ES5" implementations that are shipping today. This isn't an ES6 spec issue, it's a challenge to implementors to provide forward-compatibility. --scott -- ( http://cscott.net/ )