Check out Dart's iterators

[Allen Wirfs-Brock]

On Feb 10, 2013, at 10:40 PM, Domenic Denicola wrote:

>> From: Brendan Eich [mailto:brendan at mozilla.com]
>> 
>> Domenic Denicola wrote:
>>>> -----Original Message-----
>>>> From: Brendan Eich [mailto:brendan at mozilla.com]
>>>> Sent: Sunday, February 10, 2013 03:20
>>> 
>>>> Changing from hasMore/getNext to current/moveNext does not eliminate two methods that can get out of sync. You can imagine one is a property, not a method, but the general case is a getter or C#-style Current method.
>>> 
>>> Ah, the fact that it could be a getter does reduce it to the original two-out-of-sync-methods case, right. Thanks!
>> 
>> Rather, current *must* be a getter (or really, a method). The iteration protocol abstracts over all implementations using structural type(s), where the signature(s) must be the same for all iterators. Not all iterators want to expose a writable data property, .current.
>> 
>> Or did you mean a non-configurable, non-writable data property named current that is updated by moveNext? That would make all iterators be exotic objects, which is a non-starter.
> 
> I don't see why all iterators would have to have the same "kind" of property descriptor? I.e. if one iterator wanted a getter, and others wanted a writable, configurable data property, what's the problem there? It seems your structural type(s)/signature(s) comment is heading in this direction, but I don't understand why.

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. 

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

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.

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?

Allen