> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130412/74679639/attachment.html>

> 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.