Why can’t for-of be applied to iterators?

Brendan Eich brendan at mozilla.com
Wed Jun 12 12:00:40 PDT 2013


Andreas Rossberg wrote:
> On 12 June 2013 19:51, Brendan Eich<brendan at mozilla.com>  wrote:
>> The @iterator part of the iteration protocol is not about coercion or types
>> at all. It is a "pattern" for getting or creating a usable iterator from an
>> object.
>
> You are entitled to call it what you think is best, of course, but in
> the current state of affairs, implicit coercion is the only thing
> @iterator actually gives you. Simple test: if you removed it from the
> picture (in favour of for-of just accepting iterators) that would be
> the only thing you'd lose.

Your rebuttal leaves it a matter of indifference what either of us calls 
it, but the "implicit" part is not at issue. The "coercion" is. You are 
taking a typed point of view, wanting something even most type systems 
can't express: that a fresh iterator is either always or never returned.

I think that's simply not useful based on copious experience in Python 
and JS.

> On 12 June 2013 20:14, Brendan Eich<brendan at mozilla.com>  wrote:
>> Claude Pache wrote:
>>> Le 12 juin 2013 à 18:14, Andreas Rossberg<rossberg at google.com>   a écrit :
>>>
>>>> On 12 June 2013 14:12, Claude Pache<claude.pache at gmail.com>   wrote:
>>>>> <snip>
>>>>>
>>>>> On the other hand, I see a small advantage of the "weird" requirement
>>>>> for iterators to be iterables themselves: It allows to discriminate between
>>>>> true iterators and merely  "nextable" objects.
>>>> And in the spirit of "duck typing", why would you want to do that?
>>> Just so that an error is surely thrown in case I feed a for/of loop with a
>>> non-iter{ator|able}. In the spirit of duck-typing, I consider that "having
>>> an `@@iterator` method" is a more robust check than "having an `@@iterator`
>>> or a `next` method". Not a big deal, however.
>> I think it is a medium-sized deal :-).
>>
>> First, it's conceptually cleaner to have one symbol-named property test than
>> two, symbol and then string name fallback.
>>
>> Second, it is indeed more robust in this instance: 'next' is a common name,
>> with many contextual meanings and likely uses.
>
> I am a bit surprised to see you on the opposite side of the "duck
> typing" fence all of a sudden. ;)

Please, no false dichotomies. I wrote on this thread yesterday that 
duck-typing via a symbol is more robust than via a string-name. It's 
still duck typing, though.

>>>> And
>>>> how do you want to treat an iterable with a 'next' method, but whose
>>>> @@iterator method does not return 'this'? Is that a "true" iterator?
>>>> (The fact that such a beast can even exist shows how fuzzy those
>>>> notions are.)
>>> You're right, but I don't expect to encounter such a beast often.
>>> Concretely, they are buggy objects that would not receive any special
>>> treatment (they are iterable whenever an `@@iterator` method is expected,
>>> and they are iterated whenever a `next` method is required).
>> This just isn't a problem in practice. Let's solve real problems, look at
>> cowpaths and nearby cliffs, not try to push boilerplate onto all programmers
>> out of an off-target desire to make get- at iterator a "type coercion".
>
> Huh? The suggestion in question _reduces_ boiler plate, namely the
> need for every iterator to implement a braindead @@iterator method.

Yes but at the price of *every* for-of on an array, e.g., to call a 
values() iterator constructor. Count the right beans. Implementors of 
iterators are relatively few, especially given generators.

Failing to scale arguments about boilerplace costs by target 
victim-audience size is a capital mistake.

/be


More information about the es-discuss mailing list