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

Andrea Giammarchi andrea.giammarchi at
Tue Jun 11 11:07:22 PDT 2013

so you are saying instanceof would be bad while 'nextable' (same 'thenable'
concept) is a better approach?

Ages ago, I was using PHP SPL a lot and found the interface approach very
simple and nice, it's more suitable for Proxy objects in JS though...
that's why I've talked about mixin, to drop repeasted code that will
implement same thing for every ArrayLike object: (Empty Iterator)

I also think is hard to distinguish between for/in'able' and for/of'able'
since first kind always worked with pairs/entries like objects while second
seems to be more ... well ... complicated for no concrete reason (from a
user prospective)

In any case, if a generic next(){} function to attach to any instance would
make it iterable then is fine and easy enough to explain.


On Tue, Jun 11, 2013 at 11:01 AM, Allen Wirfs-Brock
<allen at>wrote:

> On Jun 11, 2013, at 10:22 AM, Andrea Giammarchi wrote:
> I believe Iterator should be an interface and not a class so I could
> extend Array or ArrayLike implementing Iterator, when/if necessary, in
> order to have a for/of compatible class.
> We don't have interfaces ... I know, we could have mixins though,
> compatible with @@things too.
> Even if we had an Iterator abstract class, it would simply be there as an
> connivence for Iterator implementors.  I would never specify for-of as
> doing a instanceof-like check on Iterator.  Duck-typing is what is need in
> this situation.
> While we don't have interfaces as a linguistic form,  we use implicit
> interfaces all the time.  Any duck-typing check, whether explicit or
> implicit (via an unguarded method call) is conceptually checking for an
> implicit interface.
> Allen
> My 2 cents
> On Tue, Jun 11, 2013 at 9:41 AM, Brandon Benvie <bbenvie at>wrote:
>> On 6/11/2013 5:50 AM, Tab Atkins Jr. wrote:
>>> On Tue, Jun 11, 2013 at 2:08 AM, Axel Rauschmayer <axel at>
>>> wrote:
>>>> On the other hand, turning every iterator into an iterable puts the
>>>> burden
>>>> on people implementing iterators: they have to implement the iterable
>>>> interface.
>>> That's... not really a burden.  It's literally just adding an
>>> @@iterator method whose body is "return this;".  It's the right place
>>> to put the burden, too - manual iterator authors are much, much fewer
>>> than for-of users.
>> It may be worth noting that, while it hasn't made it into the ES6 spec
>> (yet?), the iterators strawman [1] (and modules_standard strawman [2]) had
>> an `Iterator` class that all the builtin iterators (Map, Set, Generator,
>> etc.) inherited from who's prototype had @@iterator built in. So usually
>> the only burden for iterator authors was to create a class that inherited
>> from Iterator.
>>     import { Iterator } from '@iter';
>>     class MyIterator extends Iterator { /*...*/  }
>> [1]**doku.php?id=harmony:iterators<>
>> [2]**doku.php?id=harmony:modules_**standard<>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list