Rewinding iterators

Marcus Stade marcus at stade.se
Mon Apr 7 12:06:20 PDT 2014


Thanks Allen! When reading the issue, I can't quite make out what the
reasoning is for setting this constraint on the iterator protocol. Locking
down the behavior of Map/Set/Array iterators is fine I suppose (although
I'd argue against the permanently closed behavior) but I reckon it seems a
bit overkill to specify that custom iterators must have the same behavior.
It seems arbitrary, but perhaps more importantly I'm not sure how engines
should enforce this behavior or why this added complexity is necessary. If
engines don't enforce it, then this language doesn't really matter much for
the general iterator protocol *anyway.* I'm also very open to the
possibility that I've misunderstood the whole thing.

Much obliged to for your feedback!

-- Marcus


On Mon, Apr 7, 2014 at 5:47 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> see https://bugs.ecmascript.org/show_bug.cgi?id=2003 which was the
> original issue that motivated the currently spec'ed  behavior.
>
>
>
>
>
>
> On Apr 7, 2014, at 3:30 AM, Marcus Stade wrote:
>
> Thanks for filing that! Now I also know where to file bugs, so doubly
> thanks!
>
> -- Marcus
>
>
> On Mon, Apr 7, 2014 at 10:00 AM, David Bruant <bruant.d at gmail.com> wrote:
>
>>  Le 07/04/2014 02:31, Marcus Stade a écrit :
>>
>> In section 25.1.2 of the spec<http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:working_draft_ecma-262_edition_6_04-05-14.pdf>it says:
>>
>> The function returns an object that conforms to the IteratorResult
>>> interface. If a previous call to the next method of an Iterator has
>>> returned an IteratorResult object whose done property is true, then all
>>> subsequent calls to the next method of that object must also return an
>>> IteratorResult object whose done property is true,
>>>
>>
>> Are there any practical reasons why the Iterator interface explicitly
>> disallows this?
>>
>> There is no good reason indeed. Worse, there is no way to enforce it on
>> user-generated iterators, so it'd be dangerous for standard iterator
>> consumers to assume such a property.
>>
>> This mention should probably be removed altogether.
>> Filed https://bugs.ecmascript.org/show_bug.cgi?id=2606
>>
>> Thanks,
>>
>> David
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140407/489a6322/attachment.html>


More information about the es-discuss mailing list