On Tue, Jun 22, 2010 at 10:15 AM, Allen Wirfs-Brock < [email protected]> wrote:
> 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: > I haven't observed controversy so much as confusion, but perhaps I missed something. In any case, +1 on both suggestions below. > > 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 > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
