Yet more ambiguities in property enumeration

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Tue Jun 22 10:15:20 PDT 2010


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: es5-discuss-bounces at mozilla.org [mailto:es5-discuss-
> bounces at mozilla.org] On Behalf Of Allen Wirfs-Brock
> Sent: Tuesday, June 15, 2010 1:18 PM
> To: stay; Oliver Hunt
> Cc: Mark S. Miller; es-discuss; brendan at mozilla.com; es5-discuss at mozilla.org
> 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:stay at google.com]
> > Sent: Thursday, June 03, 2010 11:54 AM
> > To: Oliver Hunt
> > Cc: Allen Wirfs-Brock; Mark S. Miller; es5-discuss at mozilla.org;
> > es-discuss; brendan at mozilla.com
> > Subject: Re: Yet more ambiguities in property enumeration
> >
> > On Fri, May 7, 2010 at 1:00 PM, Oliver Hunt <oliver at apple.com> 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 google.com
> 
> _______________________________________________
> es5-discuss mailing list
> es5-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es5-discuss



More information about the es-discuss mailing list