<div dir="ltr"><div><div>Has the iteration protocol been given a close look since 
unique symbols hit the scene? I know the iterator key was 
changed to a symbol (which makes great sense) but ISTM symbols offer up some design flexibility that, as far as I know, just isn't possible in any of the other
 languages mentioned WRT prior art.<br><br>For example, the first 
argument to the iterator function could be a symbol that acts as a 
StopIteration semaphore for that iteration run. Obviously consuming an 
iterator with `for of` or comprehensions would implement the protocol for you (generating the symbol and testing 
it's identity under the covers), but it'd still be just as easy (perhaps more so) to run off an iterator run manually. If you 
happen know the full alphabet of the sequence you're iterator over you don't even 
have to use a symbol. I think it's safe to say very few sequences won't have holes, so providing nothing at all would do the Right Thing in the vast majority of cases.<br><br></div>I 
know it's too late in the game for new features. Though, this is really a small tweak to the current proposal -- it's essentially the same 
protocol with a different signaling mechanism. There sure seem to be an awful lot of pros. It's easier to get right 
than the throw StopIteration dance, and I couldn't imagine a way it 
could be less efficient. AFAICT it's not subject to the deficiencies I've seen
raised about the current spec -- no instanceof StopIteration confusion and 
no unnecessary catch blocks, for instance. I'm not aware of any cons.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 10, 2013 at 9:35 PM, Claude Pache <span dir="ltr"><<a href="mailto:claude.pache@gmail.com" target="_blank">claude.pache@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Le 10 févr. 2013 à 22:01, David Bruant <<a href="mailto:bruant.d@gmail.com">bruant.d@gmail.com</a>> a écrit :<br>
<br>
> <snip><br>
<div class="im">><br>
> I have to note that there is a minor security hazard in code using iterators naively:<br>
>    import process from "m";<br>
><br>
>    var a = [1, 2, 3, 4, 5];<br>
>    var next = 0;<br>
>    var it = {<br>
>        next: function(){<br>
>            if(next < a.length){<br>
>                // If the call to "process" throws StopIteration because it's malicious/buggy,<br>
>                // so does this code and that's largely unexpected.<br>
>                return process(a[next++]);<br>
>            }<br>
>            else{<br>
>                throw StopIteration;<br>
>            }<br>
>        }<br>
>    }<br>
><br>
> You can always protect yourself by wrapping the call to "process" with a try/catch block.<br>
</div>> <snip><br>
<br>
<br>
Note that the same issue arises with generators:<br>
<br>
        function* gen(a) {<br>
                var next = 0;<br>
                if (next < a.length) {<br>
                        // the iterator will end prematurely if "process" throws a StopIteration<br>
                        yield process(a[next++]);<br>
                }<br>
        }<br>
<br>
In order to mitigate the problem, instead of throwing a generic StopIteration, I think we ought to throw a specific StopIteration instance with information on which iterator has thrown. More precisely, inside a generator function, a return statement will throw a StopIteration instance with its "source" property set to the generator iterator which was terminated.<br>


<br>
For manually throwing a StopIteration from inside a "next" method of an iterator, we could use:<br>
<br>
        throw new StopIteration(this)<br>
<br>
And instead of "e instanceof StopIteration", we may use a more precise check:<br>
<br>
    e instanceof StopIteration && e.source === it<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
—Claude<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</div></div></blockquote></div><br></div>