Axel Rauschmayer wrote:
The idea that iterators return themselves from their @@iterator
(__iter__) hook has years of actual programmer mileage in Python. I
take that experience seriously, compared to arguments from purity
that tax the common use-cases.
I’d be happy with either solution, but let’s compare:
AFAICT, the tax is on for-of (and Array.from()): they need to
additionally check whether an object is an iterator.
On the other hand, turning every iterator into an iterable puts the
burden on people implementing iterators: they have to implement the
iterable interface. And it becomes harder to distinguish the
interfaces, should you need to [1].
This is two-edged: if you want an iterator to be iterable other than by
returning itself, you can do that with the Pythonic protocol on which we
based the ES4/6 design.
IMO, the purity argument also counts: this technique implies that
iterators are a subset of iterables, but that isn’t true: For
iterables, each invocation of `iterator` creates a new object, for
iterators, it doesn’t.
That's a matter of definition or choice-of-axiom, though.
As an aside, Python 3 uses a special name for the `next` method (it
previously didn’t). Maybe ES6 should use a symbol here, too. That
would eliminate the concerns about false positives, should for-of ever
work with iterators.
There's no need for two symbols, @iterator and @next, given the first.
The Pythonic protocol we based the design on always calls @iterator,
avoiding false positives.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
