How to clean up __proto__ (was: Why we need to clean up __proto__)

Axel Rauschmayer axel at
Thu Dec 29 00:29:58 PST 2011

Smart. These would be like the dict proposal [1].

It might make sense to encapsulate this, e.g. as a constructor StringMap. Rationale: allows you to use a shim on older systems. And you have to change existing code, anyway.

In the shim, one could avoid creating excess garbage by only prefixing keys ending with "__proto__". For "__proto__" itself, one could cache the prefixed key, for others having the suffix, one would only do so to make absolutely sure that keys never clash.


On Dec 29, 2011, at 2:39 , Mark S. Miller wrote:

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

Dr. Axel Rauschmayer
axel at


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list