Check out Dart's iterators

[Oliver Hunt]

On Feb 11, 2013, at 8:54 AM, Jason Orendorff <jason.orendorff at gmail.com> wrote:

> 
> 
> 
> On Sun, Feb 10, 2013 at 4:05 PM, Oliver Hunt <oliver at apple.com> wrote:
>> It turns out (at least in Python) that while you rarely have to directly implement the raw iterator protocol, you seriously almost *never* have to directly consume it. So it was the right design decision, in Python at least, to optimize the protocol for ease of use on the *implementing* side.
> 
> Sorry, I don't follow what you're saying here - which implementer? the language implementer or the developer?
> 
> Developer.
>  
> using the python example below your iterator would be:
> 
> function myCustomGenerator() {
>     while (line = this.readline())
>        yield line
> }
> 
> Agreed. The raw iterator protocol only ever matters if you're trying to avoid the generator overhead or something.

Saving the cost of "generator overhead" by making all iteration technically slower by depending on exceptions (correct semantics mean even optimising out the throw is tricky for default iteration generators).

Additionally get the correct behaviour for StopIterator is non-trivial as you aren't simply doing "throw StopIterator" you have to do "throw StopIterator(magic value that you know consumer will check for)"

For now I would say that we shouldn't expose the internal implementation behaviour of yield (which is what being able to explicitly create or call a generator produces).  That fairly trivially resolves the StopIteration behaviour by pushing it out of the ES6 spec.  If there's enough demand for manually creating or 'calling' a generator then we can fix it in ES6.x/7

> 
> -j

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130211/0ea4a314/attachment-0001.html>