==
Allen Wirfs-Brock
allen at wirfs-brock.com
Wed Apr 29 19:09:30 UTC 2015
On Apr 29, 2015, at 11:12 AM, C. Scott Ananian wrote:
>
> Since it's `Promise.then` you care about, I think the approach in my previous message (where `then` is tested directly) is preferable.
I agree. If what you specifically care about is the `then` behavior you should be checking for a known good `then` method rather than something you think implies that `then` will be good. It's exploitable errors in the implication logic are the source of the problem.
class DefensivePromise extends Promise {
constructor(x) {
super(x);
if (new.target === DefensivePromise) {
Object.freeze(this);
}
}
static resolve(x) {
switch (true) {
default:
// 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
return new this(r => {r(x)});
}
}
Object.freeze(DefensivePromise);
Object.freeze(DefensivePromise.prototype);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150429/182f7904/attachment-0001.html>
More information about the es-discuss
mailing list