==

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