John, You may want to take a look at streamline.js.
It is a preprocessor that generates either pure callbacks or code for node-fibers (thanks to Marcel who did all the hard work here). I had started to investigate a third preprocessing option to target generators but I stopped because I could only play with generators in Firefox and they did not implement the full harmony stuff (especially the generator delegation feature which make life a lot simpler with nested callbacks). My gut feeling is that streamline source should be easy to translate to generators but the proof is always in the pudding... Preprocessing can be viewed as a really ugly solution but it has one big advantage: it allows you to change the targeted platform and take advantage of future features without having to change your source code. Bruno On Feb 10, 9:48 pm, "john.tiger" <[email protected]> wrote: > the issue for us is that quick maintainability is as important as > performance - the example of mongo query nested callbacks (like in the > tests of node-mongo-native) is just way too messy (and if everyone else > thinks it's fine then I'm in the 1% that don't). > > I'll check out common-node - I actually had considered Narwhal but when > I saw all those java libs - yuk! Maybe better for those already in java > environments. I like to keep stuff simple. > > On 02/10/2012 01:06 PM, Oleg Podsechin wrote: > > > > > > > > > > > but, common-node (and maybe some other libraries) have abstracted > > away that callback when you're living in their abstraction by > > using fibers under the hood (i'm sure Oleg will pop in any minute > > to explain how). the way yield is described for generators does > > not lend itself to ever being abstracted to that degree. > > > Thanks for mentioning Common Node Mikeal. For anyone who wants to > > check it out, here's a link:http://olegp.github.com/common-node/ > > > There's nothing too fancy going on. I've just created synchronous > > wrappers for all modules that do IO. As a result, no code outside my > > library should yield, addressing the interleaving hazard concern that > > some have expressed. In fact, I've been meaning to add a mechanism > > which detects yields in the application code and displays a warning. > > > I do mean to make a fork of the library which uses generators once > > they're available. The upgrade path should be fairly straightforward > > with the yield keyword added before any method that does IO. However, > > based on this comment > >http://erik.eae.net/archives/2011/12/29/00.00.29/#comment-104393it > > looks like generators won't be in Node for another year or so. > > > Oleg > > -- > > 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 -- 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
