Question about [[Enumerate]] and property decision timing

[Jordan Harband]

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 <utatane.tea at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150810/8e5e35c4/attachment.html>