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!
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
