It should not be enumerated.
In general properties are seen via the accessing object. That's what
[[GetOwnProperty]] (8.12.1), which is used though the spec, does. It starts
with "b" looking for 'x' walking the [[Prototype]] chain, as necessary. It
stops when it finds a own property definition for 'x' and the uses the
attributes of that property definition. It never looks further up the
[[Prototype]] chain once such a property is found.
There are all sorts of ways that a property definition can shadow an
inheritable property definition, it can change data property to an accessor
property, it can make non-configurable property configurable, etc. None of
these are special cased, the "closest" property definition always wins.
Remember that historically, IE behaved as follows:
var obj = {toString: false, xxx: true};
var props=[];
for (var p in obj) props.push(p);
alert(props); //legacy IE displays "xxx" not "toString, xxx"
There was universal agreement that IE was wrong and all other browsers were
correct in enumerating toString even though it shadows a non-enumerable
property.
What you are describing is just the opposite situation. Consistency requires
use the closest property definition and ignore what it shadows rule.
Allen
> -----Original Message-----
> From: stay [mailto:[email protected]]
> Sent: Thursday, June 03, 2010 11:54 AM
> To: Oliver Hunt
> Cc: Allen Wirfs-Brock; Mark S. Miller; [email protected]; es-discuss;
> [email protected]
> Subject: Re: Yet more ambiguities in property enumeration
>
> On Fri, May 7, 2010 at 1:00 PM, Oliver Hunt <[email protected]> wrote:
> >
> > On May 7, 2010, at 12:56 PM, stay wrote:
> >> Really? How could sites possibly depend on being able to mark
> >> properties non-enumerable but still have them appear in a for-in loop?
> >
> > Sorry, shadowing with a non-enumerable property is new to ES5, I was
> meaning the behaviour i described is what we need to do to ensure sites work.
> >
> > Now days my understanding is the only place where there is confusion over
> behaviour is purely which prototype properties should be enumerated.
> >
> > --Oliver
>
>
> I don't think I ever saw a conclusive answer to the original question:
>
> When a.x is enumerable, b inherits from a, and b.x is marked non-enumerable,
> does x get enumerated in a for-in loop or not?
>
> If not, V8 and WebKit are doing it wrong. If so, it seems to violate the
> principle
> that properties on children shadow their parents.
>
> Which is it?
>
> Allen's follow-up messages talked about order of enumeration, which I'm not
> particularly concerned about right now.
> --
> Mike Stay
> [email protected]
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
