Mariusz Nowak wrote:
+1!It would be great if someone will explain in detail why Object.setPrototypeOf is no go.
We've been over this many times, e.g. at https://mail.mozilla.org/pipermail/es-discuss/2012-May/022904.html To recap,1. __proto__ is out in the field, a de-facto standard on "mobile", and not going away. Adding another API doesn't help, it hurts.
2. SES and other secure subsets want same-frame (global object, "realm") mashups of code that may use __proto__ and code that must not, but Object.setPrototypeOf is a per-frame capability that would have to be removed, breaking the former class of code.
Any function that blindly extends object with provided hash is affected e.g.
extend(obj, { __proto__: Error.prototype }).
No, that depends on how extend works. If it uses Object.defineProperty or equivalent, then nothing is broken and the setter on Object.prototype for __proto__ is not run.
Additionally it means that we need to serialize any user input which eventually may be used as key on a dictionary e.g. data[userDefinedName].
Only if you use assignment into an object that delegates to Object.prototype, but see (1) above: this hazard already exists. Don't do that; JSON doesn't, and Object.create(null) gives a way to create dictionaries.
Yes, the problems you cite are real, but they are already part of the de-facto __proto__ standard (1). Beyond that, Object.setPrototypeOf is a mistake due to (2).
/be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
