Oops, this wasn't really about for-in. In Object.defineProperties should really be (inerted new step 3 and modified renumbered step 4:
1. If Type(O) is not Object throw a TypeError exception. 2. Let props be ToObject(Properties). 3. Let names be an internal list containing names of each enumerable own property of props 4. For element P of names in list order, a. Let descObj be the result of calling the [[Get]] internal method of props with P as the argument. b. Let desc be the result of calling ToPropertyDescriptor with descObj as the argument. c. Call the [[DefineOwnProperty]] internal method of O with arguments P, desc, and true. 5. Return O. If an implementation defines a specific order of enumeration for the for-in statement, that same enumeration order must be used to order the list in step 3 of this algorithm >-----Original Message----- >From: [email protected] [mailto:es-discuss- >[email protected]] On Behalf Of Allen Wirfs-Brock >Sent: Wednesday, August 12, 2009 2:34 PM >To: Jeff Walden; [email protected] >Subject: RE: The precise meaning of "For each named own enumerable >property name P of O" > >ES5 section 12.6 (for-in statement) says: > >The mechanics and order of enumerating the properties (step 6.a in the >first algorithm, step 7.a in the second) is not specified. Properties of >the object being enumerated may be deleted during enumeration. If a >property that has not yet been visited during enumeration is deleted, >then it will not be visited. If new properties are added to the object >being enumerated during enumeration, the newly added properties are >guaranteed not to be visited in the active enumeration. > >ES3 says pretty much the same thing with minor wording tweaks. > >>-----Original Message----- >>From: [email protected] [mailto:es-discuss- >>[email protected]] On Behalf Of Jeff Walden >>Sent: Wednesday, August 12, 2009 1:04 PM >>To: [email protected] >>Subject: The precise meaning of "For each named own enumerable property >>name P of O" >> >>What is the behavior when the body of the loop may have side effects? >>There are a number of these for the Object.* hooks, but I'm most >>specifically considering Object.defineProperties, in the case when some >>getter executed in the body of that loop (also in ToPropertyDescriptor) >>results in a new property being added, a future property being removed, >>a property being readded with the same name (does it attempt to define >>the property twice?) -- all the usual enumeration hazards, but most >>particularly the last one because of potential weirdness of defining >the >>same property twice with conflicting attributes between the two >property >>descriptors (if the appropriate behavior were specified to trigger >>that). >> >>Jeff >>_______________________________________________ >>es-discuss mailing list >>[email protected] >>https://mail.mozilla.org/listinfo/es-discuss > >_______________________________________________ >es-discuss mailing list >[email protected] >https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
