4 ms·
I think your assumption about no call blocking libs leading to a mess is under the assumption that people see a need for a blocking lib with Node. The assumptio
by randall 15y ago
I think your assumption about no call blocking libs leading to a mess is under the assumption that people see a need for a blocking lib with Node. The assumption by default is that every call is async. Even calls which happen instantly sometimes offer a callback pattern because that's what people who use node often expect.
I can't personally envision a situation where an NPM module would update to change a call to blocking spontaneously. This is the reason why we're using Node in the first place.
Non-blocking is the default. The community assumes and expects non-blocking calls by default.
- peterhunt 15y agoI find it very easy to imagine myself writing some code that assumes a function doesn't need to do I/O, and then lo and behold the spec changes and we have to refactor the entire call stack of anything that assumes it's nonblocking.
- tlb 15y agoI haven't had much difficulty avoiding such cases. It can come up if you have a simple fixed function that returns its value, but later decide to make it customizable through the database. When that happens, it's not very hard to make the callers use a callback.
- artsrc 15y agoSome changes are breaking changes. If a call requires new parameters and there are no sensible defaults then clients have to change to supply those parameters. I am sure this will be misunderstood but anyway... The initial Java world made IO exceptions checked exceptions, this implied that the addition of IO was a breaking change in that model also.