Re: [webidl] Fix some problems with iterable declarations. (#72)

>                      <li><a href="#es-invoking-callback-functions">Invoke</a> <var>callback</var> with <var>thisArg</var>
>                        as the <a class="dfnref" href="#dfn-callback-this-value">callback this value</a> and
> -                      <var>k</var> and <var>value</var> as its arguments.</li>
> +                      <var>value</var>, <var>key</var> and <var>O</var> as its arguments.</li>
> +                    <li>Update <var>pairs</var> to the current list of <a class="dfnref" href="#dfn-value-pairs-to-iterate-over">value pairs to iterate over</a>.
> +                      <div class="note"><div class="noteHeader">Note</div>
> +                        <p>Depending on whether prose accompanying the interface defined this to be a snapshot at the time

Having notifications to handle the Map/Set behaviour would mean that spec prose would need to interact with the "value pairs to iterate over" by explicitly saying "insert a pair at index i" or "remove a pair at index j", rather than defining more declaratively what the list would be at any given moment.  That's pretty awkward.  And in any case pairs could be removed and re-inserted at later indexes and be iterated over multiple times, which from the ES spec it sounds like Maps/Sets shouldn't do.  One thing that makes it a little easier for Maps/Sets is that new entries go at the end and can't be inserted at arbitrary indexes.

I don't think we need to allow spec authors to choose between iteration behaviour that ensures we get all entries, and one based on simple indexes that means we might skip some.  I can't see why there'd be good reasons to choose differently for different APIs.

An easier way to spec the "ensure we don't skip any entries" iteration behaviour: at each iteration of the loop (for forEach) or invocation of next (on the default iterator object), we scan the list for the first pair whose key isn't present in a set of handled keys that we maintain, then we invoke the callback / return that entry.  As written that's quadratic time, but we could leave it to implementors to work out to handle the common case of the list of value pairs *not* changing, or to inform the iterator about entries that were inserted/removed (using some knowledge of the particular API being implemented), without needing the spec author to specify that.  That might not always be easy, depending on how "dynamic" the definition of the list of pairs is...

---
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/72/files#r45026337