d at domenic.me (2015-05-11T16:47:37.819Z)
On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote: > It's not clear what the `x.constructor` test is still doing in your implementation. Do you mean the first or second occurrence? > > But, regardless of the details of our implementations, can we agree that "tamper proof" promises don't seem to need the [[PromiseConstructor]] property? I agree with you, but I'm not the Promise champion. Regardless, too late for ES2015. It will have to proposed as an ES2016 change.
On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote: > On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: > class DefensivePromise extends Promise { > constructor(x) { > super(x); > if (new.target === DefensivePromise) { > // I'm assuming this test is just to be subclass friendly and allow subclasses to freeze later? > Object.freeze(this); > } > } > static resolve(x) { > switch (true) { > default: > // I guess a do { } while(false); would work as well? > // assuming frozen primordial > if (x.constructor !== DefensivePromise) break; //just a quick exit, doesn't guarantee much > if (!Object.isFrozen(x)) break; > If (Object.getOwnPropertyDescriptor(x, 'then')) break; > //a more subclass friendly approach would walk x's [[Prototype]] chain to ensure that the correct 'then' is inherited from frozen prototypes > if (Object.getPrototypeOf(x) !== DefensivePromise.prototype) break; > //Assert: x.then === Promise.prototype.then, now and forever after > return x; > } > // must be called on a subclass of DefensivePromise, so we don't need to enforce the 'then' invariant > If (x.constructor === this) return x; //in which case a constructor check is good enough > // ^^ this is a mistake right? I think this line doesn't belong. > return new this(r => {r(x)}); > } > } > Object.freeze(DefensivePromise); > Object.freeze(DefensivePromise.prototype); > > It's not clear what the `x.constructor` test is still doing in your implementation. Do you mean the first or second occurrence? > > But, regardless of the details of our implementations, can we agree that "tamper proof" promises don't seem to need the [[PromiseConstructor]] property? I agree with you, but I'm not the Promise champion. Regardless, too late for ES2015. It will have to proposed as an ES2016 change. Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150429/73443991/attachment.html>