How to clean up __proto__ (was: Why we need to clean up __proto__)
reichsteinatwork at gmail.com
Thu Dec 29 03:38:08 PST 2011
There is one side-effect to defining __proto__ using a getter/setter
property. You can extract the setter and store it for later, allowing
you to change the prototype of objects after someone else deleted the
That means that if you're not the first script to run on a page, you
can't know for sure that you can remove the setting-of-proto ability.
But then again, if you're not the first script to run, you can't even
know that you can remove it, or trust anything ever again, so it's not
really a (new) problem, more of an observation.
I.e., by extracting the setter, you can create a
setPrototypeOf(object, newProto) function:
var setPrototypeOf =
On Thu, Dec 29, 2011 at 2:39 AM, Mark S. Miller <erights at google.com> wrote:
> [Oops. Actually changing the Subject: this time]
> [change of Subject: as this reply starts the promised thread]
> Hi Lasse, good. That is the direction Dave Herman suggested and which I also
> find attractive. I have elaborated it at
> which I've also placed on the Agenda for the January EcmaScript meeting.
> The most surprising punchline is in requirement #4:
> Object.create(null), creating an object that does not inherit from
> Object.prototype, also creates an object that does not inherit it’s
> __proto__, even if that property has not been deleted. With this change,
> objects-as-stringmaps for objects created by Object.create(null) would avoid
> the __proto__ hazard, even in contexts where Object.prototype.__proto__ has
> not been deleted. (FF already acts this way, so my previous message was
> wrong in claiming that Object.create(null) fails to avoid this platform on
> all non-IE browsers.)
> Comments on this proposal appreciated.
> On Wed, Dec 28, 2011 at 5:26 PM, Lasse Reichstein
> <reichsteinatwork at gmail.com> wrote:
>> The biggest problem with __proto__, as I see it, isn't that you can
>> hit it accidentally, but that even if you know what you are doing, you
>> can't avoid it (and have to do expensive workarounds).
>> It obviously depends on the implementation. In Mozilla
>> Firefox/*Monkey, __proto__ is an inherited accessor on
>> Object.prototype (just as __define[SG]etter__). It's not an
>> own-property and you can shadow it.
>> In Chrome/V8, it's an artificial own property on every object, and it
>> can't be removed, shadowed or ignored. It tries to emulate Safari's
>> original implementation, but probably fails some details (as your
>> tests show, they aren't the same).
>> I like the Firefox way much better, both as a user and as an
>> implementor. Since we probably can't get rid of __proto__ totally, I
>> would cheer if implementations would change to the Mozilla way.
>> /L 'entirely my personal opinion'.
More information about the es-discuss