You beat me to it with your example, still i think that binding on every call is a bad idea.
Including the context every time is unpleasant, and it will get even worse when you want to use apply. It also does not improve the readability of the code ( .bind is just creating noise all over the place ). On 17 April 2014 21:27, willem dhaeseleer <[email protected]> wrote: > Alex, > > Do you have an example of any coroutine / promise library that supports > passing in an callback styled function without wrapping / binding ? > You would have to pass in the context and arguments separately for every > every call, that seems very cumbersome to me. > > You could yield a binded function to improve it somehow, but binding on > every call sounds like a bad idea as well. > In any event, I think that pre-wrapping callback styled functions is a > requirement to deal efficiently with coroutines in javascript. > > > > > > On 17 April 2014 21:13, Alex Kocharin <[email protected]> wrote: > >> >> You *can* have coroutines without promises. Good coroutine wrappers will >> just curry any yielded function assuming that the last argument is a >> callback. >> >> >> 16.04.2014, 17:34, "willem dhaeseleer" <[email protected]>: >> >> Using just promises with a good library will off course already give you >> the asynchronous callstacks / error propagation. >> So it's really only the coroutines that are improving readability / >> maintainability, but you can't have coroutines without promises, or some >> sort of abstraction around callbacks. >> >> >> On 16 April 2014 15:26, willem dhaeseleer <[email protected]> wrote: >> >> Charlie, >> >> I actually agree that promises them self don't really contribute to much >> to the readability of code. >> It's only when you combine them with generators to create co-routines >> that you truly benefit from improved readability and asynchronous >> callstacks / error propagation which can be really helpful during debugging >> as well. >> >> >> >> >> >> >> >> >> On 16 April 2014 15:05, Charlie McConnell <[email protected]>wrote: >> >> I would like to argue with the increase in readability - it doesn't exist. >> >> Promises are an overly verbose "solution" to a simple problem, and are >> not an appropriate global replacement for callbacks in every case. Saying >> so is misleading and disingenuous. >> >> If you want something universally usable, use callbacks, and let the >> consumers of your library wrap them in all the promises they want to. >> Wrapping a callback in a promise is less work than taking apart a promise >> into a callback, making this the most widely useful approach. >> >> Using solely promises is only going to contribute to the increasing >> fragmentation of this community into sects, each revolving around its >> (primarily cosmetic) abstractions of choice. >> >> -- >> Charlie McConnell >> >> >> On Wed, Apr 16, 2014, at 03:34 AM, willem dhaeseleer wrote: >> >> That fact that node core api's only support callbacks doesn't make them >> holy. I understand they used callbacks back in 2009 before >> the proliferation of asynchronous control flow in javascript and the state >> of promises in V8 / ECMAScript . But today promises are in V8 and wildly >> used and you just can't argue with increase in readability, maintenance and >> productivity. >> I'm sure we could have a lengthy discussion about what makes a good api, >> but I think most people will agree with me that consistency should be key. >> Providing both promises and callbacks in your api seems like a very bad way >> to go. >> >> The node core API also doesn't really define a *standard*, it defines an >> interface, I believe there are even some methods in the api that don't even >> respect the *callback(err, >> result)*<http://nodejs.org/api/fs.html#fs_fs_exists_path_callback> format. >> >> The standard is ECMAScript, and ECMAScript 6 has promises, and >> generators, use them where applicable. >> >> >> >> >> >> >> >> On 16 April 2014 12:02, greelgorke <[email protected]> wrote: >> >> my only concern about your post is that you simply ignore the standards >> in node. node core apis are callback based, your 3rd party libs should >> honor this. a good api doesn't care much about personal opinions and a) >> supports the standard and b) provides optional methods for convinience. >> >> it's not about whats better. its about what a good api >> >> Am Mittwoch, 16. April 2014 10:27:18 UTC+2 schrieb willem dhaeseleer: >> >> >> Hey greelgorke, >> >> Great to get some feedback on my answer, I'll try to clarify my arguments >> some more here: >> >> >> - It always you to pass on asynchronous operations >> >> huh? >> >> // foo returns promise >> var futureBar = foo(); >> >> // you can know pass around futureBar to some other api or use it for >> later reference >> // with callbacks you will have to write your own wrapper code to get >> this type of "asynchronous encapsulation" >> >> >> - How many types have you typed *if (err) throw err *or *if (err) >> console.warn(err) ?* >> >> you actually type this yourself? >> >> Off course not, but i have seen it in to much code already. >> Obviously i forgot* if (err) return callback(err);* >> If haven't written in this style anymore for a long time. >> >> >> - Improved readability trough more logical control flow >> >> duh. readability is subjective. >> >> Off course it's subjective, but chronological reading order is something >> I tend to value in most code. >> Just my opinion. >> >> >> - Integration with coroutines ( you want this ) >> >> huh? how is that connected? >> >> An example should clarify this, this uses bluebird: >> This is obviously a bad use of a database, but the idea is to demonstrate >> how promises integrate with coroutines. >> >> >> var getTotalFriendBalance = Promise.coroutine(function* (name) { >> var user, userFriends, x, totalBalance; >> user = yield db.getUserByName(name); >> userFriends = yield db.getFriends(user.id); >> for (x = 0; x < userFriends.length; x++) { >> totalBalance += (yield db.getAccountInfo(userFriends[ >> x].id)).balance; >> } >> return totalBalance; >> }); >> >> >> I challenge you to write this peace of code with only callbacks, I think >> you will find this syntax is much more intuitive and more pleasant to write. >> This is only possible because all asynchronous methods here return >> promises (or thenables) that can be used by the coroutine. >> >> I hope this clarifies my personal opinion on why promises are better. >> >> >> >> >> On Wednesday, April 16, 2014 9:50:22 AM UTC+2, greelgorke wrote: >> >> inline >> >> Am Mittwoch, 16. April 2014 08:46:48 UTC+2 schrieb willem dhaeseleer: >> >> >> Andrew, >> >> For the love of all that is dear to us, Use promises, do not support >> callbacks, don't even think about supporting both. >> There is a reason why promises are becoming part of the standard in ECMA >> 6. >> >> >> they are there to give you an alternative, not a replacement. Callbacks >> are simple for simpler things. they are the core pattern and they are >> accepted. every single person new to node, can just use them, as soon she >> understood async coding style. >> >> it is a very bad habbit to only provide promises api. one of the top3 >> popular modules on npm is async, which handles callbacks. >> >> So, stop crying about callbacks, learn them and provide a cb-based >> interface. and stop saying us. :P >> >> >> >> Here are a few of many reasons why to choose promises: >> >> - It prevent deep indentation >> >> flatten your code. >> >> - It always you to pass on asynchronous operations >> >> huh? >> >> - Asyncronous callstacks and consistent error handling ( you want this ) >> - How many types have you typed *if (err) throw err *or *if (err) >> console.warn(err) ?* >> >> you actually type this yourself? >> >> - Refactoring in callback styled code is extremely tedious to the point >> where it would be almost reasonable to say it's impossible >> >> it always hard to refactor bad written code either with callbacks, >> promises or even synchronous code. >> >> - Improved readability trough more logical control flow >> >> duh. readability is subjective. >> >> - Integration with coroutines ( you want this ) >> >> huh? how is that connected? >> >> >> >> >> On Tuesday, April 15, 2014 6:20:05 AM UTC+2, Andrew de Andrade wrote: >> >> So at work we're working on a bunch of node modules that will eventually >> be published as open-source and I'm in favor of callbacks and two of my >> co-workers are in favor of promises. We've discussed supporting both API >> interfaces and I was curious what the general consensus of the community >> was with respect to supporting both and the best way to name functions and >> methods to support both. >> >> That being said, there are three obvious choices: >> >> (a) two function types: (1) synchronous functions; and (2) async >> functions that return promises but also handle callbacks >> >> var value = myFunctionSync(); >> myFunction(callback); >> var promise = myFunction(); >> >> this approach has a tiny performance overhead (since you have to check if >> the last argument is a function to determine if you should return a promise >> or execute that function as the callback) and makes all the functions a >> little convoluted (unless you make one higher order function that you apply >> to all your callback functions to support both APIs). Furthermore async, >> higher order, overloaded functions or variable arity functions become >> impossible since you can't necessarily assume that the last argument is >> always the callback. >> >> (b) three function types: (1) synchronous functions; (2) async callback >> functions; and (3) async promise functions >> >> var value = myFunctionSync(); >> myFunction(callback); >> var promise = myFunctionDeferred(); >> >> this is ugly but explicit in terms of what to expect and permits the most >> flexibility. >> >> (c) two function types: (1) synchronous functions; (2) async callback >> functions; >> >> var value = myFunctionSync(); >> myFunction(callback); >> >> and promise support is left up to the user by using a nodeify() method >> from a promise library. This is my preference, but won't make my co-workers >> happy. >> >> >> With all this in mind, what's the general consensus of the NodeJS >> community on this issue? I searched google and the archives and could not >> find any blog posts or discussions that address this particular issue. What >> are the pros and cons of each approach? What if any libraries implement >> options (a) or (b)? etc. >> >> >> >> >> -- >> -- >> 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 a topic in the >> Google Groups "nodejs" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/nodejs/NpZ4WT1eOnw/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> -- >> -- >> 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/d/optout. >> >> >> >> -- >> -- >> 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 a topic in the >> Google Groups "nodejs" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/nodejs/NpZ4WT1eOnw/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> -- >> 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/d/optout. >> >> -- >> -- >> 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 a topic in the >> Google Groups "nodejs" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/nodejs/NpZ4WT1eOnw/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- -- 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/d/optout.
