> Le 3 mars 2015 à 23:19, Guilherme Souza <[email protected]> a écrit :
>
> My use case is similar to what Dean has showed:
>
> My `run()` lib abstraction should work with:
>
> * a function, with node's done() callback style
> * a generator function, with co's yield promise style [1]
>
> ```
> // ES5 function
> run(function (data, done) {
> doSomeAsyncJob(data, done)
> })
>
> // Generator function
> run(function* (data) {
> return yield getSomeAsyncJobPromise(data)
> })
> ```
>
> [1] https://www.npmjs.com/package/co <https://www.npmjs.com/package/co>
The hard part is that you should take the "generator function" path for
functions that *behave* like generator functions even if they are not, e.g.,
`gen.bind(null, 'foo')`, where `gen` is a true generator function.
This is how I'd consider to do, if I *really* couldn't ask the user about the
nature of the function.
1. At first, don't make any assumption about which code path to take. Let `f`
be the function to work with;
2. As a common part of the algorithms for the two cases, call `f(data, done)`,
assuming that it is equivalent to `f(data)` if `f` is a generator function;
3. Check whether the result is iterable, i.e, if `typeof
result[Symbol.iterator] === 'function'`. If yes, proceed with the "generator
function" path. If no, proceed with the "function-with-callback" path.
—Claude
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss