Allow to use generators

[piranna]

Allow to use EcmaScript 6 iterators and generators instead of Array objects.

[aearly]

Unless I'm misunderstanding, isn't that what visionmedia/co is about, rather than async?

[piranna]

No, they are different things. Co is about flow control using generators, that's mostly an intelligent hack. What I'm talking about is to use generators in the same way that async.js use arrays for data processing in a similar way of Python itertools, where you can be able to use any iterable object (any object that implement the iterator protocol, like lists, dicts and generators).

[megawac]

Support could be added pretty easily to keyIterator and iterator I think

[aearly]

A quick workaround is async.map([...generator()], doSomething, done), but iterating over a lazy iterator would open up some cool control flow options.

[aearly]

Closing this in favor of #839 -- I think supporting arbitrary ES6 iterators covers a lot of things -- Maps, Sets, Generators, etc...

[piranna]

Yes, both issues are similar.

[aearly]

I just realized that generators don't implement the iterator protocol, meaning we'll need separate support for them. This will prove to be tricky, since there doesn't seem to be a bulletproof way to detect generator functions.

[megawac]

@jdalton any interest in adding _.isGenerator =)

[megawac]

Actually nevermind there's no reason for us to detect whether its a generator @aearly, if the iterable passed to keyIterator is a function we can just execute it and process the result as an iterator?

http://stackoverflow.com/a/19660350/1517919

[aearly]

It's really tricky, since our iterator handling checks an object for a [Symbol.iterator] method, then calls .next() on the result of that method. For a generator, it would call the function itself, then call .next() on the result. I'm not sure if being "nextable" is sufficient enough.

[aearly]

Perhaps internal/getIterator could check to see if the function's prototype matches a generator function's prototype. (Like in that stackoverflow question). I don't know how portable that strategy would be across JS engines, though. A robust _.isGenerator function would make this trivial to implement....

[megawac]

I'd say if item is a function, we call the function assuming it will follow
generator protocol. Does that not suffice for our use case?

On Thu, Jun 30, 2016 at 5:22 PM, Alex Early [email protected]
wrote:

Perhaps internal/getIterator could check to see if the function's
prototype matches a generator function's prototype. (Like in that
stackoverflow question). I don't know how portable that strategy would be
across JS engines, though.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#579 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ADUIECpwzLMYv9QPFq0SDaLF0RClBwJrks5qRDOEgaJpZM4CLfkD
.

[aearly]

The only pitfall I can think of is when someone accidentally passes a function as the wrong arg -- you'd get an error like "undefined has no property next". Right now, I think it would try to iterate over the own properties of the function.

Can't think of any use case where passing a function would be a valid use case in the future, so it might be sufficient.

[131]

meanwhile, i am in need of async's signatures with async/await (through ES6 generator & co) supports. So, i ended up writing a dedicated project for it async-co.

[aearly]

I think our current support is sufficient. You can do this today, and it works:

function* gen(count) {
  for (var i = 0; i < count; i++)
    yield i;
}

async.map(gen(5), (val, cb) => {
  cb(null, val * 2)
}, (err, res) => {
  // res = [0, 2, 4, 6, 8]
})

The generator support was within us the whole time. 👸 🌠 👠