Mike Stay (cc'ed) noticed the following ambiguity:
What should the following print?
var base = {x:8};
function showProps(obj) {
var result = [];
for (var k in obj) {
result.push(k, ': ', ''+obj[k], '\n');
}
return result.join('');
}
var derived = Object.create(base, {x: {value: 9, enumerable: false}});
showProps(derived);
Of current ES5 implementations in progress,
* TraceMonkey and SES5/3 (Mike Stay's emulation of the Secure subset of
EcmaScript 5 strict on current ES3R browsers) currently gives
the empty string,
meaning that the non-enumerable "x" in derived shadows the enumerable "x"
from base.
* WebKit nightly and V8 currently gives
"x: 9"
meaning that the enumerable "x" from base shows through, causing the above
loop to look up the value of the unenumerable shadowing "x" property.
I have not tested any other partial ES5 implementations (Rhino,
ObjectPascal, ??).
The relevant test seems to be ES5 section 12.6.4 step 6.a (and likewise 7.a
for the next production):
Let P be the name of the next property of obj whose [[Enumerable]]
attribute is true.
>From this text, I think either interpretation is possible. However, since a
common pattern for using for-in uses the enumerated key to look up the
corresponding value on the object being enumerated (e.g., "obj[k]" above), I
think that the more useful interpretation is the one currently employed by
TraceMonkey and SES5/3.
I think a clarification of this issue be added to the ES5 errata. I propose
that this clarification adopt the more useful suppression behavior, and
suggest that ES5 implementations in progress switch to that behavior.
Whichever disambiguation is adopted, I'll be happy to file bugs against the
implementations with the non-conforming behavior. We should also add a test
for this to es5conform.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
