Discuss
  • The ES6 iteration protocol

The ES6 iteration protocol

# Axel Rauschmayer (10 years ago)

FWIW: I have written down my understanding of the ES6 iteration protocol (shaped by discussions I had on this mailing list).

gist.github.com/rauschma/73e5f86a595b7709f39e

# Dmitry Soshnikov (10 years ago)

Good write up, although "fresh vs singleton" topic doesn't make sense, and doesn't reflect the spec. I responded on the gist.

Dmitry

# joe (10 years ago)

Regardless of what the spec says, you cannot avoid singleton iterators in real-world code. In my opinion, the spec should refrain from specifying when object creation happens within the iteration protocol, wait for the relevant code and contract patterns to develop and then include something in ES7.

# Dmitry Soshnikov (10 years ago)

I guess all built-in iterators return themselves for Symbol.iterator protocol. So they are all "singletons". I described in detail where confusion/substitution of concepts happens in that analysis in the recent two comments.

Dmitry

# Allen Wirfs-Brock (10 years ago)

On Apr 6, 2015, at 2:23 PM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com> wrote:

I guess all built-in iterators return themselves for Symbol.iterator protocol. So they are all "singletons". I described in detail where confusion/substitution of concepts happens in that analysis in the recent two comments.

I don’t think “singleton” is the correct term for the concept that Axel is trying to describe. A “singleton” is normally an kind of object for which there is only a single instances. There may be many instances of, for example %ArrayIterator%, so it isn’t correct to call %ArrayIterator% a singleton

What Axel is describing might be characterized as “self iterable”, it returns itself when recieving a Symbol.iterator request.

# Dmitry Soshnikov (10 years ago)

Exactly, that's what I tried to explain. Since in one case it considers just an iterable (an array), and in other case -- an iterator (which is by "coincidence" is also an iterable). But an array's iterator is an iterable as well, and also always returns itself for iterator protocol.

Yeah, the "self-iterable" makes much more sense in this case.

Dmitry

# Axel Rauschmayer (10 years ago)

There are two different aspects:

  1. If you get an iterable, it sometimes matters whether iteration restarts when you ask the iterable for an iterator.
  2. Self-iterability is how iterators turn themselves into iterables so that constructs that work with iterables can be used. It also enables generators to play two roles: generator methods can implement [Symbol.iterator] and generator functions can implement iterable-returning functions.

In this particular case, I’m interested in #1. I probably have to come up with a better term for it.

# Brendan Eich (10 years ago)

Axel Rauschmayer wrote:

There are two different aspects:

  1. If you get an iterable, it sometimes matters whether iteration restarts when you ask the iterable for an iterator.

Rather, if you have an object o and o[Symbol.iterator]() === o then you have an iterator.

  1. Self-iterability is how iterators turn themselves into iterables so that constructs that work with iterables can be used. It also enables generators to play two roles: generator methods can implement [Symbol.iterator] and generator functions can implement iterable-returning functions.

I'm not clear on what 2 means. Generator functions definitely return generator-iterators when called. A generator function gf does not have a gf[Symbol.iterator] property, though.

In this particular case, I’m interested in #1. I probably have to come up with a better term for it.

Yes, "singleton" is the wrong word. Perhaps you want "iterator"? :