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

Andreas Rossberg rossberg at google.com
Wed Jun 12 17:00:36 PDT 2013


On 12 June 2013 21:00, Brendan Eich <brendan at mozilla.com> wrote:
> 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'm not sure where you took that from. What does it matter what type
systems can express?

>>> 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.

There must be some confusion here. Yes, I said earlier that I wouldn't
mind dropping the implicit magic altogether, but that isn't what the
current subthread is about, where I suggested another alternative,
which is (somewhat) simplifying the current model by viewing @iterator
as an implicit conversion. That doesn't imply any of the above.

/Andreas


More information about the es-discuss mailing list