comments like this make me scratch my head. there are thousands of developers here on this mailing list maintaining node code using callbacks. there are products that do daily deploys across thousands of node processes that use callbacks.
there are hundreds of thousands of liberal arts graduates using and maintaining code that uses jquery (with callbacks!). if you think that callbacks are a blocker for maintainability i can't help but wonder why all these other people seem to be fine but the it's such a blocker for you that you would need to opt out of what the vast majority of the community are using, testing, and running in production every day. On Feb 10, 2012, at February 10, 20123:48 PM, john.tiger 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-104393 it 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 -- 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
