<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 9, 2015, at 2:34 PM, Yusuke SUZUKI wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi forks,
<div><br></div><div>Recently, we implemented Reflect.enumerate in WebKit JSC.</div><div>At that time, the question is raised "When are the enumerated keys determined?"[1]</div><div><br></div><div>For example,</div><div><br></div><div>var object = ...;</div><div>var iterator = Reflect.enumerate(object);</div><div>object.newKey = "hello";</div><div>// At that time, iterator.next() is not called yet.</div><div>for (var key of iterator) {</div><div>    print(key);   // Here, "newKey" should be produced or not?</div><div>}</div><div><br></div><div>Seeing the spec, I think it's a little bit ambiguous. (correct?)</div></div></blockquote><div><br></div><div>The ES6 spec. text for ordinary object [[Enumerate]] [2] was directly derived from the ES5.1 spec. text for the for-in statement [3]. The  ES5.1 spec. text is a minor elaboration upon the corresponding text in the E3 spec. In ES3 and ES5 many details of for-in processing were left unspecified (ie, implementation dependent) because that reflected the reality of web browsers and it did not seem feasible at that time to force browsers to change their for-in implementations.</div><div><br></div><div>ES6 moved part of the for-in enumeration into the [[Enumerate]] internal method and and added some additional semantic requirements.  But it also did not change the policy established in the previous editions of not fully specifying the semantics.  This decisions could certainly be revisited for future editions. My sense is that a fully specified for-in/[[Enumerate]] would have a better chance of finding acceptance today, than it would have in the past.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div>In the current WebKit implementation, keys are cached when the iterator is created.</div></div></blockquote><blockquote type="cite"><div dir="ltr"><div><br></div><div>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. "?</div></div></blockquote><div><br></div><div>This sounds like it is a valid implementation.  The quoted sentence was not intended to imply that nothing happens until the first `next` method call.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div><br></div><div>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."?</div><div><br></div><div>And is the creation of the iterator by calling [[Enumerate]] included in "active enumeration"?</div></div></blockquote><div><br></div>The "active enumeration" was intended to start with the the call to [[Enumerate]].  <br><blockquote type="cite"><div dir="ltr"><div><br></div><div><br></div><div>[1]: <a href="https://bugs.webkit.org/show_bug.cgi?id=147677">https://bugs.webkit.org/show_bug.cgi?id=147677</a></div><div><br></div><div>Best regards,</div><div>Yusuke Suzuki</div></div></blockquote><div><br></div>Allen<br><br></div><div>[2]: <a href="http://ecma-international.org/ecma-262/6.0/#sec-ordinary-object-internal-methods-and-internal-slots-enumerate">http://ecma-international.org/ecma-262/6.0/#sec-ordinary-object-internal-methods-and-internal-slots-enumerate</a> </div><div>[3]: <a href="http://www.ecma-international.org/ecma-262/5.1/#sec-12.6.4">http://www.ecma-international.org/ecma-262/5.1/#sec-12.6.4</a> </div><br></body></html>