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
}
}
```
On Wed, Jan 8, 2014 at 1:18 PM, Bruno Jouhier <[email protected]> wrote:
> Alex,
>
> I developed galaxy as a pure generators alternative to streamline, with
> the hope of switching to a pure JS solution in the future.
>
> But after some experiments with it I decided to stay with streamline,
> simply because the syntax is more concise and plays better. For example,
> here is how you chain 3 async calls with streamline:
>
> function asyncFn4(_) { return asyncFn1(_).asyncFn2(_).asyncFn3(_); }
>
> and the same thing with galaxy:
>
> function* asyncFn4() { return (yield (yield (yield
> asyncFn1()).asyncFn2()).asyncFn3()); }
>
> More keystrokes, more difficult to parse visually, more risks of mistakes
> (closing parenthesis in the wrong spot, forgetting a yield), etc.
>
>
> And other generators libraries won't do any better because the problem
> comes from yield's precedence. They'll likely even require more code, like
> a wrapper around every async function definition.
>
> Fibers, with the default futures library, preserves the nice chaining:
>
> function asyncFn4() { return asyncFn1().wait().asyncFn2().wait().asyncFn3();
> }
>
> But this is less efficient than the corresponding streamline code (in
> fibers mode) because every asyncFnN() call allocates a future (streamline
> optimizes this case).
>
> I'm probably a bit extreme in my quest for concise and composable syntax
> but these things matter when you deal with a big code base.
>
> Bruno
>
>
>
> On Wednesday, January 8, 2014 9:13:42 AM UTC+1, Alex Kocharin wrote:
>
>>
>> I'm not looking for async stack trace. If I were, I'd probably pick up
>> "trycatch" module instead.
>>
>> What I'm asking is that what is the point of writing javascript if you
>> can't use it without compiling?
>>
>> If you can use a compiler, you can use typescript, iced coffee and a
>> dozen languages better than javascript. If you don't want to use a
>> compiler, fibers and generators will help without any streamline stuff. So
>> what is the point...
>>
>> -----
>>
>> I'm using callbacks only. People who don't understand them just can't
>> work with node, so I have no regrets about that. The biggest drawback so
>> far was that debugger can't step in async calls, don't know what to do
>> about it.
>>
>> If I wanted to write sync-like code, I'd probably turn to generators and
>> "co" module. It looks nice, but I didn't actually manage to try it, since
>> generators aren't on by default even in 0.11.x...
>>
>>
>> // alex
>>
>> 08.01.2014, 11:37, "Bruno Jouhier" <[email protected]>:
>>
>> The async stack is reconstructed when you *catch* the exception (would be
>> very inefficient otherwise). The normal pattern is to have at least one try
>> catch in your high level HTTP dispatcher. You actually automatically get
>> one if you use the companion streamline-streams or ez-streams companion
>> libraries.
>>
>> Try the following:
>>
>> function a(_) { return b(_); }
>> function b(_) { return c(_); }
>> function c(_) { return d(_); }
>>
>> function d(_) {
>> setTimeout(_, 1000);
>> throw new Error("xx");
>> }
>>
>> try { a(_); }
>> catch (ex) { throw ex.stack; }
>>
>> Output:
>>
>> Error: xx
>> <<< async stack >>>
>> at d (/Users/bruno/dev/syracuse/junk/stack._js:7:18)
>> at c (/Users/bruno/dev/syracuse/junk/stack._js:3:23)
>> at b (/Users/bruno/dev/syracuse/junk/stack._js:2:23)
>> at a (/Users/bruno/dev/syracuse/junk/stack._js:1:23)
>> at main (/Users/bruno/dev/syracuse/junk/stack._js:10:6)
>> <<< raw stack >>>
>> at __$d (/Users/bruno/dev/syracuse/junk/stack._js:7:18)
>> at ___ [as _onTimeout] (/Users/bruno/dev/syracuse/
>> node_modules/streamline/lib/callbacks/runtime.js:100:13)
>> at Timer.listOnTimeout (timers.js:124:15)
>>
>>
>>
>>
>> On Wednesday, January 8, 2014 3:45:25 AM UTC+1, Alex Kocharin wrote:
>>
>>
>> I run "node_ test._js", then "node debug -p `pidof node`" (node_ doesn't
>> have debug option), and that's the code I see:
>>
>> ```
>> debug> c
>> break in test._js:4
>> 2 debugger ;
>> 3 return setTimeout(__cb(_, __frame, 2, 0, function __$main() {
>> 4 debugger ;
>> 5 console.log("... world"); _(); }, true), 10000);
>> });}).call(this, __trap);
>> 6 });
>> ```
>>
>> And this is an example stack trace:
>>
>> ```
>> Error: xx
>> at __$main (/tmp/node_modules/zz/test._js:5:16)
>> at ___ [as _onTimeout] (/tmp/node_modules/streamline/
>> lib/callbacks/runtime.js:100:13)
>> at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)
>> ```
>>
>> Needless to say, I don't remember writing any of these underscore
>> methods. And as I said earlier, I avoid compilers for this exact reason.
>> Personally, I'd much rather stick to the callbacks and not trade writing
>> time for debugging time. But if you're using a compiler anyway, I'd rather
>> look for await/defer features of IcedCoffeeScript because it comes with
>> much more obvious syntax.
>>
>> PS: yes I know, it's possible to use fibers or generators or whatever
>> with streamline. But I can use them without streamline just as well, and
>> it'd be much easier.
>>
>>
>> 08.01.2014, 05:55, "Seth Pollack" <[email protected]>:
>>
>> Hi Alex, please see my comment below about not trolling for more "my
>> control flow is better than your control flow" debates ;-)
>>
>> All joking aside, there are many innovative approaches out there -- an
>> embarrassment of riches. For folks who are into coffee script, streamline
>> has full support for that as well.
>>
>> Also, i may not have been clear enough about the debugging experience
>> under streamline. The code in the editor and debugger are the same.
>>
>> Seth
>>
>>
>> On Tuesday, January 7, 2014 4:49:42 PM UTC-8, Alex Kocharin wrote:
>>
>>
>> I wonder how having different code in the editor and in the debugger
>> helps productivity.
>>
>> Oh come on... If you're using a compiler anyway, why not move to iced
>> coffee or something? I'm avoiding it recently, but it's still better than
>> streamline.
>>
>>
>> 07.01.2014, 22:53, "Seth Pollack" <[email protected]>:
>>
>> I've written up a blog post here http://bit.ly/KtMIYS that explains why
>> we've chosen Node.js plus Streamline as our platform for our product (
>> www.rivaliq.com).
>>
>> We are all Node fans in this forum, but i'm guessing that fewer folks
>> have given Streamline (https://github.com/Sage/streamlinejs) a spin. We
>> have found significant developer productivity (and happiness!) benefits by
>> making the switch to using it. I'm not saying that here to troll for more
>> "my control flow is better than your control flow" debates, but rather to
>> share our experiences in order to hopefully help others. Please give it a
>> read, and I welcome your comments on the blog.
>>
>> Seth
>>
>> --
> --
> 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.
>
--
--
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.
