Sure, but it's takeIterable and statefulMapIterableWith which I was wondering about. They are themselves callables which return iterables. Is there any reason not to write them as generator functions?
That's great; you've really made this clear. In python, one would just use itertools.tee() to get multiple bites at a particular iterator, rather than relying on sugary syntax to instantiate the iterator multiple times; perhaps ES6 should have something similar? I have to say, this "Symbol.iterator" magic string seems like an even less felicitous way to write this than python's dunderous __iter__() function. Maybe coffeescript or one of its forks can help ES explore a more reasonable way to write this.
Well, __iter__ was baked into Python decades(?) ago, so there’s no danger anybody might have their own __iter__ methods that mean something else. But now that JS is adding iteration methods to the language, there are lots of libraries and frameworks that have their own incompatible ways of greenspunning these features.
The [Symbol.iterator] expression resolves to a string that is guaranteed to be unique, so there is no possibility of breaking backwards-compatibility with someone who picked the exact same magic name.
(There’s a major headache involved when code crosses execution contexts, I don’t pretend to understand how that works yet.)
Ah, the penny drops. Thanks. I've actually been bitten by not paying attention to the same distinction in python, which I evidently haven't quite learned the lesson of yet.