On 03/14/2013 04:14 PM, Brendan Eich wrote:
Andreas Rossberg wrote:
On 14 March 2013 23:38, Brendan Eich<[email protected]> wrote:
Andreas Rossberg wrote:
That leaves my original proposal not to have generator application
return an iterator, but only an iterable. Under that proposal, your
example requires disambiguation by inserting the intended call(s) to
.iterator in the right place(s).
That's horribly inconvenient. It takes Dmitry's example:
function* enum(from, to) { for (let i = from; i<= to; ++i) yield i }
let rangeAsGenerator = enum(1, 4)
let dup = zip(rangeAsGenerator, rangeAsGenerator) // Oops!
which contains a bug under the Harmony proposal, to this:
function* enum(from, to) { for (let i = from; i<= to; ++i) yield i }
let rangeAsGenerator = enum(1, 4)
let dup = zip(rangeAsGenerator[@iterator](), rangeAsGenerator[@iterator]())
No, why? The zip function invokes the iterator method for you.
Sure, but only if you know that. I thought you were advocating explicit
iterator calls.
A call expression cannot be assumed to return a result that can be consumed by
some mutating protocol twice, in general. Why should generator functions be
special?
I agree they could be special-cased, but doing so requires an extra allocation
(the generator-iterable that's returned).
Meanwhile the Pythonic pattern is well-understood, works fine, and (contra
Dmitry's speculation) does not depend on class-y OOP in Python.
I guess it's the season of extra allocations, but still: in general when I
consume foo() via something that mutates its return value, I do not expect to
be able to treat foo() as referentially transparent. Not in JS!
Does for-of accept only iterables, only iterators, or both? Presumably a function like
zip would make a similar decision. The problem is if the answer is "both".
Waldemar
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
