Check out Dart's iterators

[Brendan Eich]

Allen Wirfs-Brock wrote:
> To me, Domenic appears correct on this point. The difference between a "method" (a function valued property that is intended to be explicitly called) and a "state property" (not explicitly called, might be implemented as either a accessor or data property) is the only thing that matters at the signature description level.

Maybe, but the difference is observable, and a data property has a 
defensive-coding smell.

> Also, a non-configurable, non-writable by clients property doesn't require an exotic object.  It can be implemented using a get accessor

I specified data property, after allowing for the getter alternative. 
Let's not go in circles.

>   and some private state (pick you favorite mechanism).  Iterators must have other private state to operate so a private "current" doesn't seem like it would be much of an added burden.

Are you actually trying to change the accepted ES6 proposal here?

"doesn't seem like it would be much of an added burden..."  -- hmm, 
where have I heard that before.

http://vimeo.com/25606006

"It's not much of a problem" === "It's a problem."

> Finally, I don't see why we would even worry about a client modifying .current.  So what if a client of an iterator (of the moveNext/current model)  modifies current.  What are we afraid of?  That somebody is going to modify current and a few lines later forget that they did so?  Seems like a mundane client bug, nothing that needs to be protected against.

In a single-trust-domain small-world code network, sure -- whatever.

In a programming-in-the-large setting, a writable data property is 
inviting Murphy's Law. I'm not talking about security in a mixed-trust 
environment specifically. Large programs become "mixed trust", even when 
it's just me, myself, and I (over time) hacking the large amount of code.

> Finally, why the big concern about out of sync iterator methods. Being out of sync is just a bug, and one that is not likely to go undiscovered.  Why is this any worse than any other object with multiple methods that are supposed to present a consistent view of some state?  This isn't something that we generally worry about, so why is it an issue here?

We've been over this, it's in the meeting notes and the es-discuss post 
that I linked to up thread. I get tired of re-searching and re-posting 
these links. You should get tired of reading them, for some balance :-|.

The problem of out-of-sync doesn't exist with ES6 iterators or Python 
iterators. More, the bigger point to make is that developers who do code 
implementors don't have to write two methods, as Jason pointed out.

/be