I don't understand the motivation for this change. It seems like most of the __proto__ replacements here actually make things worse. Maybe it isn't really from the other bugs, but `__proto__` inside an object literal is not a setter. If we remove the `Object.prototype.__proto__` getter/setter in the future those uses will still work. Unless the value on the right can be controlled it should even be preferred over changing the [[Prototype]] later using the Object.setPrototypeOf function. (I think most of the old performance issues with that were fixed though)
Bug 1803800 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I don't understand the motivation for this change. It seems like most of the `__proto__` replacements here actually make things worse. Maybe it isn't really from the other bugs, but `__proto__` inside an object literal is not a setter. If we remove the `Object.prototype.__proto__` getter/setter in the future those uses will still work. Unless the value on the right can be controlled it should even be preferred over changing the [[Prototype]] later using the Object.setPrototypeOf function. (I think most of the old performance issues with that were fixed though)
I don't understand the motivation for this change. It seems like most of the `__proto__` replacements here actually make things worse. Maybe it isn't really obvious from the other bugs, but `__proto__` inside an object literal is not a setter. If we remove the `Object.prototype.__proto__` getter/setter in the future those uses will still work. Unless the value on the right can be controlled it should even be preferred over changing the [[Prototype]] later using the Object.setPrototypeOf function. (I think most of the old performance issues with that were fixed though)