Of course I can use all sorts of API/functional twists to improve things
but:
1) Code will still be more difficult to read. For example, compare:
function asyncFn4(_) { return asyncFn1(_, a, b).asyncFn2(_, c, d,
e).asyncFn3(_, f); }
and:
function asyncFn4(_) { return yield(asyncFn3(yield asyncF2(yield asyncF1(a,
b), c, d, e), f); }
asyncFn3 and its argument (f) are completely split apart. And this is not
even real code: things get worse when arguments are complex parameters
containing parentheses (with more risks of parentheses pairing errors).
You can also do:
function asyncFn4(_) { return yield util.chain(["asyncFn1", a, b],
["asyncFn2", c, d, e], ["asyncFn3", f]);
Better. But to me this looks less like JavaScript (where are the functions?
ah yes, those string literals!), more like code that a preprocessor would
generate (and this is the kind of code that streamline generates in fibers
and generators mode). And there is more noise (line gets longer).
2) Why should we have to twist our APIs to cope with deficiencies of our
async tools? In sync-land you have the choice between target.fn(arg) and
fn(target, args). Both have a very terse notation and target.fn(arg) just
works better in many situations (array.filter(fn1).map(fn2).reduce(fn3) for
example). Why should things be different in async-land? The goal of
streamline is to allow you to use *all* JS constructs in a natural way,
even if you are in async-land. It tries to keep the syntactic overhead as
low as possible. Most of the time, the syntactic overhead is reduced to an
extra _ parameter, and this is a very useful visual clue because it tells
you where your code does yield to the event loop.
3) What about training overhead? If you have a growing team, you'll need to
get newcomers up to speed and give them lots of guidelines (favor
composition over chaining, use helper xyz). I'm not saying that streamline
has 0 cost but once you know that _ means "wait" (and yield) and !_ means
"don't wait" (and return a future on which you'll be able to wait later),
you know most of it and you can start to use your existing JS skills to
write async code.
But as I said earlier I probably have an obsession with the signal to noise
ratio in code. If you find the alternatives ok (gap between asyncF3 and f,
util.chain helper), then fine. I'm ready to pay the price of a transparent
pre-processing pass to get the leanest code possible.
On Thursday, January 9, 2014 4:06:52 AM UTC+1, Raynos wrote:
>
> your asyncFn4 chaining problem can be solved with functional programming
> and composition
>
> Rather then using `this` implicitely in chaining format you can pass the
> argument in.
>
> ```
> function* asyncFn4(arg) {
> // I hope the yield order works like what you would expect here :/
> return (yield asyncFn3(yield asyncFn2(yield asyncFn1(arg)));
> }
>
> // as seperate calls. pretty ugly but linear and not LISPY
> function* asyncFn5(arg) {
> var res = yield asyncFn1(arg);
> var res2 = yield asyncFn2(res);
> var res3 = yield asyncFn3(res2);
> return res3;
> }
>
> // manually compose and call
> function* asyncFn6(arg) {
> return yield* compose([asyncFn1, asyncFn2, asyncFn3])(arg)
> }
>
> // point free style function composition
> var asyncFn6 = compose([asyncFn1, asyncFn2, asyncFn3])
>
> // compose is really simple with yield in for loops.
> function compose(fns) {
> return function* (result) {
> for (var i = 0; i < fns.length; i++) {
> result = yield fns[i](result);
> }
> return result
> }
> }
> ```
>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
