On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote:
> On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock <[email protected]>
> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
