Yet more ambiguities in property enumeration

Allen Wirfs-Brock Allen.Wirfs-Brock at
Tue Jun 15 13:18:29 PDT 2010

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.


> -----Original Message-----
> From: stay [mailto:stay at]
> Sent: Thursday, June 03, 2010 11:54 AM
> To: Oliver Hunt
> Cc: Allen Wirfs-Brock; Mark S. Miller; es5-discuss at; es-discuss;
> brendan at
> Subject: Re: Yet more ambiguities in property enumeration
> On Fri, May 7, 2010 at 1:00 PM, Oliver Hunt <oliver at> 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
> stay at

More information about the es-discuss mailing list