I interpreted this spec text (and the included generator code example) to mean that the first "next" is the thing that determines the keys to be enumerated - since the generator function body (including the Reflect.ownKeys call) is not executed until that point.
The question was also raised on that linked bug, why does the spec leave behavior undefined for keys added during enumeration? It seems like the spec should either dictate that added keys are *not* enumerated, or, that they are *always* enumerated. On Sun, Aug 9, 2015 at 2:34 PM, Yusuke SUZUKI <[email protected]> wrote: > Hi forks, > > Recently, we implemented Reflect.enumerate in WebKit JSC. > At that time, the question is raised "When are the enumerated keys > determined?"[1] > > For example, > > var object = ...; > var iterator = Reflect.enumerate(object); > object.newKey = "hello"; > // At that time, iterator.next() is not called yet. > for (var key of iterator) { > print(key); // Here, "newKey" should be produced or not? > } > > Seeing the spec, I think it's a little bit ambiguous. (correct?) > In the current WebKit implementation, keys are cached when the iterator is > created. > > Does this violate the spec behavior, "The iterator’s next method processes > object properties to determine whether the property key should be returned > as an iterator value. "? > > Or, is it implementation dependent because "If new properties are added to > the target object during enumeration, the newly added properties are not > guaranteed to be processed in the active enumeration."? > > And is the creation of the iterator by calling [[Enumerate]] included in > "active enumeration"? > > > [1]: https://bugs.webkit.org/show_bug.cgi?id=147677 > > Best regards, > Yusuke Suzuki >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
