On 15 March 2013 01:13, Brendan Eich <[email protected]> wrote: > Andreas Rossberg wrote: >> >> See my reply to Jason: I think that in most practical cases (in >> particular, all abstractions over iterables), the invocation of the >> iterator method will happen inside an abstraction, and the programmer >> does not have to worry about it. > > Talking 1:1 with you after the TC39 meeting, it came out that the ES6 spec > does not say that iterators are iterables whose @iterator does "return > self". That changes things, but still makes a messier contract than you > prefer.
Yes. Iterators have a next method, that's all what makes them an iterator, according to the wiki, and having an iterator method is never mentioned there. The only place where such a case shows up in the proposals is for generator objects. > The contract you prefer is one where iterables have @iterator and calling it > gets a (mutable) iterator that is *not* an iterable. It would require, as > you proposed, making generators return iterables not iterators -- an extra > allocation. > > At the level of contract cleanliness and usability, that may be better than > the Pythonic convention -- I'm not sure. Cc'ing Jason. > > At the level of extra allocations, I still say "boo". I'd say that one allocation per loop is perfectly affordable -- and is likewise required for packaging up the return value. For both it is easy to avoid ever materializing the extra object in the common case of a for-loop. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
