Where in spec does it explain why setting the value of an existing property will change its [[Enumerable]] attribute.

John-David Dalton john.david.dalton at gmail.com
Wed Aug 17 12:24:18 PDT 2011

> Awesome! That was our conclusion too. It was late Kit and I missed
> trying it in other implementations (instead we dug into spec because
> we thought it was odd). It turns out V8 (Chrome, Node.js) has a bug
> that will make non-enumerable properties enumerable by assigning a new
> value as in my previous snippet :O
> I suspect that this only applies to builtin properties on objects, as I
> think JSC has a similar issue.

You are right.
V8 doesn't have this problem for object properties created with
`Object.defineProperty` and friends.
Also right again, JSC does appear to have a similar issue (tested
Safari 2.0.0 - WebKit Nightly)

> Speaking for JSC (but i wouldn't be surprised if V8 did something similar)
> we will delay the creation of the majority of builtin properties until
> they're actually used, eg. until you actually access Array.prototype.reduce
> we won't reify the property.  A side effect of this is that when you simply
> assign to the property we skip reification, and so the property attributes
> are the same as you would get if you were creating a new property.
> A simple test would be to see if
> Array.prototype.reduce;
> Array.prototype.reduce = ...
> Results in the correct behaviour.

Though it does avoid the bug in JSC, accessing the property before
setting it doesn't affect V8 on built-ins as it will still bug.

I have made a simple test file here:

Another odd thing is that V8 uses the `Array#push` internally for
I noticed that if I set `Array.prototype.push = 1;` using
`Object.defineProperties(…)` would error complaining about `push` not
being a function.


More information about the es-discuss mailing list