Skorski: Forgive my ignorance, but what array iteration methods are you referring to?
Kalsow: 1, 2, 3.mapfunctionx{ return x + 1 }
Konopacki: Dolby: object 2, 3, 4
Prowell: Dolby: interesting, any reason for that preference?
Agena: That’s better than the equivalent var ys = ; for var i = 0; i xs.length; ++i ysi = xsi + 1; return ys
Konopacki: Prowell: Loops fail to clearly signal the intention of your code, and as such should be avoided whenever possible prefer higher-order functions, such as .map, .reduce, .filter, .. See also: http://qr.ae/RNMEGA and https://gist.github.com/robotlolita/7643014
Dushane: It’s sad that JS even has looping constructs in the first place :/
Sarrett: Does bluebird have any Promise.all method that will wait until all the promises have finished even if there is an error? e.g. if this is in a retry loop, I don’t want to start again while something is still running
Prowell: Old programming minds like mine couldnt function without them
Kunz: Prowell: it’s just a matter of learning new things :
Prowell: Yep, and on top of that, having the time to do so
Holte: Prowell: recursion is generally more useful.
Batter: Thanks for the insign Sorella
Purdue: Sarrett: You could adapt https://github.com/folktale/control.async/blob/master/lib/core.js#L174-L203 to promises/a+ if it doesn’t have that. But it sounds more like you want to kill running tasks if something fails than anything else
Herrada: Sarrett: promises are particularly bad for that though, since they can’t encode tasks, retries, cancelling things, etc.
Sarrett: Dolby: well, in this case the tasks are independent downloads, that are being cached
Annarumo: Sarrett: yeah, not a good use for promises.
Sarrett: So if one fails it should fail the overall task, but I can still let the others finish
Kormos: Sarrett: Promises represent values, not “actions” or “tasks”
Sarrett: A task is in many ways just a promise that has no result?
Nickless: Sarrett: a task is a process which might eventually yield a result, it might eventually fail, or it might be cancelled before you finish it. A task also has a set of resources ***ociated with it, which should be collected in any of those three cases
Vories: 3 https://www.youtube.com/watch?v=Xk_XaJ7gE4Q :
Vories: I n t e r m i s s i o n
Cotter: Does setTimeout completely stop execution of code or the code?
Sarrett: Dolby: but then if you have a task library that supports that, why would you need promises?
Sarrett: And wouldn’t the task library then look rather similar in api to say bluebird?
Vories: It’s just for that chain programming style
Sarrett: Hackal: setTimeout doesn’t stop anything, it queues up a function to run once after a delay
Birdow: Sarrett: a promise is what you get when you run a task
Rokusek: Sarrett: oh, I see now, thank you
Vories: Chilversca task is in many ways just a promise that has no result?
Sarrett: Dolby: so I then run a set of tasks, that gives me a set of promises, now I need to wait for all those promises to resolve?
Vories: Sometimes you want that
Sarrett: Isn’t that now back to the original problem I had?
Holderfield: Sarrett: yes, but if any of them fails, you can kill the other tasks.
Bintliff: Sarrett, you should have the function that returns a promise call itself again
Sarrett: But I don’t want to kill the other tasks
Wildauer: Function foo{ asyncThing.catchfoo }
Sarrett: I can’t always kill the other tasks eg, I can’t interrupt writing the file
Mendolia: Sarrett: didn’t you say that you want to retry things?
Sarrett: I don’t want to kick of a new download fo a file I’m currently wirting
Sarrett: Thus I still want to wait for that file write to complete, even if one of the other tasks has failed