Discuss
  • Iterator current/prev value

Iterator current/prev value

# Marcus Stade (10 years ago)

Could the iterator protocol be extended to also have a current or prev property, which contains the result of the previous call to next? If next has never been called, presumably this property would return undefined.

I've searched the archives for this question, and the only semi-satisfying answer I've found is this1:

Rehashed Java (hasMore/getNext) and C# (Current/MoveNext) protocols

involving two methods, which costs more for implementors (groups 2 and 3, however ordered) and adds incoherence hazard (two methods get out of sync; C# tries to mitigate common mistake with Java's, but still has dual out-of-sync hazard to Java's).

MM agreed with BE that Python's is simplest given other constraints we can't change, or "least bad".

My apologies if I'm beating a dead horse here, or my ignorance is keeping me from fully grasping the nuances of these discussions and decisions that have followed. Unless I've missed something – which is very likely – shouldn't the implementation cost for developers be virtually zero since it could/would/should be done by the very same mechanism that generators the iterator object in the first place? That is, the implementation cost is in the engine, not user land.

I can sort of understand the sync argument given that results include the done property, but couldn't the same be said for any result of calling next then? I.e. as soon as an iterator yields a result, the done property is effectively out of date and the only way to truly know whether you'll get another value is to call next and hope for the best? In any case, the return value of a current or prev property could be an object with the single property value; ensuring there's nothing that can be out of sync.

This is assuming that the current or prev property is indeed implemented by the engine and not user land, as that indeed both carries implementation cost and the risk out running out of sync. Is there any way other than generator functions to implement iterators? Are any ol' object with a function called next an iterator?

I'm probably just confused about the whole thing, and would very much appreciate to be set straight.

# Brendan Eich (10 years ago)

Marcus Stade wrote:

This is assuming that the current or prev property is indeed implemented by the engine and not user land, as that indeed both carries implementation cost and the risk out running out of sync. Is there any way other than generator functions to implement iterators? Are any ol' object with a function called next an iterator?

Any old object. It's a structural or "duck-typed" protocol.

We won't therefore be adding complexity, which is also bad on its own. KISS wins here. More elaborate protocols for harder or let's say rarer cases are fine and not part of the mandatory minimum.

# David Bruant (10 years ago)

Le 23/03/2014 19:24, Brendan Eich a écrit :

Any old object. It's a structural or "duck-typed" protocol.

Longer form at : developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/The_Iterator_protocol (reviews welcome)

# Marcus Stade (10 years ago)

On Sun, Mar 23, 2014 at 7:37 PM, David Bruant <bruant.d at gmail.com> wrote:

Any old object. It's a structural or "duck-typed" protocol.

I see, this was the bit of insight I was missing.

# Bill Frantz (10 years ago)

On 3/23/14 at 11:24 AM, brendan at mozilla.org (Brendan Eich) wrote:

Any old object. It's a structural or "duck-typed" protocol.

We won't therefore be adding complexity, which is also bad on its own. KISS wins here. More elaborate protocols for harder or let's say rarer cases are fine and not part of the mandatory minimum.

It seems it should be easy for any user or library to introduce in generalized intermediate object which implements the current or 'prev' property, so it doesn't need to be in the language.