There seems to be enough controversy about this, that it is reasonable to
clarify it a bit in the errata. There are two points that I think should be
covered:
First a normative statement at the end of the paragraph that begins "The
mechanics and order...":
A property name must not be visited more than once in any enumeration.
And a normative statement at the end of the last paragraph:
The values of [[Enumerable]] attributes are not considered when determining
if a property of a prototype object is shadowed by a previous object on the
prototype chain.
Thoughts?
Allen
> -----Original Message-----
> From: [email protected] [mailto:es5-discuss-
> [email protected]] On Behalf Of Allen Wirfs-Brock
> Sent: Tuesday, June 15, 2010 1:18 PM
> To: stay; Oliver Hunt
> Cc: Mark S. Miller; es-discuss; [email protected]; [email protected]
> Subject: RE: Yet more ambiguities in property enumeration
>
> 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]
>
> _______________________________________________
> es5-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es5-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
