for-of loops, IteratorClose and the rest of the iterations in the spec
Allen Wirfs-Brock
allen at wirfs-brock.com
Wed Sep 10 12:20:59 PDT 2014
On Sep 10, 2014, at 10:58 AM, Boris Zbarsky wrote:
> On 9/10/14, 1:47 PM, Allen Wirfs-Brock wrote:
>>> 1. Let method be the result of CheckIterable(V).
>>> 2. ReturnIfAbrupt(method).
>>> 3. If IsCallable(method) is false, go off and do something else,
>>> since V is not iterable.
>>> 4. Let iter be GetIterator(V, method).
>>> 5. ReturnIfAbrupt(iter).
>>>
>>> and then IteratorStep my way through "iter".
>>
>> So, try expressing this in JS. That's what a JS help-hosting compliant implementation is going to have to do.
>
> Sure.
>
> var method = V[Symbol.iterator];
> var method = V[Symbol.iterator];
> if (typeof method != "function") {
> // Not iterable; do something else
> }
> var iter = method.call(iter);
>
> and then go through calling .next() and so on.
>
> Now in this self-hosted case, how do I express IteratorClose?
why wouldn't a self-hoster just continue with:
for (let next of iter} {
/* body */
}
which will do all the IteratorClose work for them. In fact, isn't that how we want a self-hoster to code it. Anything either ES or WebIDL does that is hostile to that pattern is counter productive as self-hosters are probably going to do that anyway, even if the semantics is a slight mismatch to the spec.
> Seems to me like it's just a matter of wrapping the relevant bits (which ones, though?
whatever constitutes the loop "body"
> ) in a try/catch and doing this in the catch clause:
>
> catch (e) {
> if ("return" in iter) {
> iter.return();
> }
> throw e;
> }
>
> That ought to match the semantics of IteratorClose, yes?
You also will need a finally clause, if the loop body contains any explicit returns.
Allen
More information about the es-discuss
mailing list