Le 20/03/2013 16:36, Nathan Wall a écrit :
I didn't get a direct response to my question about mutating proto on objects
which don't inherit from Object.prototype, but I'm inferring from [1] that it
won't be possible. I find this unfortunate, but I realize this issue has seen
a lot of discussion in the past and there are reasons for the current decision.
I will see how I can make my code cope with reality.
Could you describe how you use __proto__ on objects not inheriting from
Object.prototype?
From what I know there are 2 main use cases:
1) object as map
changing the prototype enable changing different "default values". I
guess any solution to that problem either looses the object syntax
(maybe unless using proxies) like using an ES6 Map or has non-trivial
runtime cost.
Or the code needs to be reorganized so that the object is always created
after the prototype (using Object.create for instance)
2) Subclassing
ES6 will have classes with inheritance. That's mostly syntax sugar on
top of what's already possible, but that works.
Do you have a use case that belongs in neither of these categories?
David
Nathan
Brendan Eich wrote:
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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
