On Jun 11, 2013, at 11:07 AM, Andrea Giammarchi wrote: > so you are saying instanceof would be bad while 'nextable' (same 'thenable' > concept) is a better approach?
of course > > 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: > http://www.php.net/manual/en/class.iterator.php (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) All objects are for/in-able since for/in uses a MOP level operation that all object must support. There is nothing you can do to change its behavior short of using a Proxy. There isn't really very much conceptual complexity to Iterable/Iterator. The most important concept is that for any specific object abstraction there can be many meaningful ways to "iterate" over the information it provides. Iterator access method (keys, values, items, anything you want to define) provide a what to select a particular form of iteration. An iterator objet simply represents a specific active iteration over a particular object. Perhaps the similarity of the words "Iterator" and "Iterable" causes some confusion. I think it's fine if you want to think of "Iterable" as being equivalent to saying "nextable". > > 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. You don't attach a generic next method, you simply define an appropriate one. Allen > > cheers > > > On Tue, Jun 11, 2013 at 11:01 AM, Allen Wirfs-Brock <[email protected]> > 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 <[email protected]> wrote: >> On 6/11/2013 5:50 AM, Tab Atkins Jr. wrote: >> On Tue, Jun 11, 2013 at 2:08 AM, Axel Rauschmayer <[email protected]> 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] http://wiki.ecmascript.org/doku.php?id=harmony:iterators >> [2] http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
