> Adding Object.setPrototypeOf does not help, because code won't migrate to it > completely so we'll be stuck with two APIs.
As shown in the first post we'll be stuck with 4 APIs plus the 5th one standardized. The __proto__ that is not supported, the one that is wrongly inherited in Object.create(null), the non configurable, and the configurable without get/set > SES and similar subsets would be > unable to protect secure code from ambient > Object.setPrototypeOf usage > from the insecure side on the secure side's > objects, unless > Object.setPrototypeOf were removed -- but that would break > insecure-side > code that reasonably (per your wishes) uses > Object.setPrototypeOf in > lieu of __proto__. same way SES can protect from __proto__ it can protect from Object.setPrototypeOf redefining in a way that who's white listed can obtain same result. SES should not be that important to make decision for most web and server where SES is not the reality. As summary, I do read answers, but I haven't ever seen one strong enough. Refactoring __proto__ is 1 minute task for any library out there SES uses with() and other things for its own purpose ... SES can deal with Object.setPrototypeOf The API and the compatibility is broken regardless standardization. Being a mess is the best moment to realize that instead of being trapped behind this mess we can drop it and as soon as Object.setPrototypeOf will appear in ES6 developers will change direction I believe without many problems. The community writes shims and polyfill since 1999, I strongly doubt the easiest one ever would be so problematic. All the best
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
