4 ms·
My main point is that Promises don't have any concept of parallelism; all() is specific to the Q library, not part of Promises/A+. Obviously that's the intent—l
by _greim_ 13y ago
My main point is that Promises don't have any concept of parallelism; all() is specific to the Q library, not part of Promises/A+. Obviously that's the intent—low-level building blocks—but it leaves one feeling like Promises don't actually solve any hard problems. You still have to solve them yourself.
- ufo 13y agoBut callbacks also don't have any concept of paralelism and its trivially easy to code all() yourself once and then forget about it. The hard problem that promises solve are 1. Its more similar to regular code versus explicit CPS (no pyramid of doom, use "return" to return values, can store promises in data structures or pass them around to other functions) 2. Error handling. Regular Javascript has try-catch blocks for exception handling but those don't work with async code. Promises let you use exceptions in async code without having to worry about error callbacks.
- jkrems 13y agoPromises/A+ is not a promise library. It's not a spec about "what should a promise library do". It's about interoperability - "how can I exchange data AND promises between libraries without relying on a shared library/on everyone using the same library for flow control?". Also the spec makes error handling non-surprising, I don't need to read through the docs of a library to know how errors propagate. It looks like your promise library would have been easy to make comply with the spec by just calling "onkeep" "then" (and maybe adapting a few minor details).