Iterator current/prev value
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 this[1]: 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. [1]: http://esdiscuss.org/topic/check-out-dart-s-iterators#content-1 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. -- Marcus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Iterator current/prev value
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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Iterator current/prev value
Le 23/03/2014 19:24, Brendan Eich a écrit : 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. Longer form at : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/The_Iterator_protocol (reviews welcome) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Iterator current/prev value
On Sun, Mar 23, 2014 at 7:37 PM, David Bruant bruan...@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. Thanks! -- Marcus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Iterator current/prev value
On 3/23/14 at 11:24 AM, bren...@mozilla.org (Brendan Eich) wrote: 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. 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. Cheers - Bill --- Bill Frantz| Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
