Square with the promise of being an async API

[sethfitz]

Async API is async. (Sorry, the link to support this this isn't handy.)

[yhahn]

Heh is this a new convention.

[sethfitz]

Not really. All it does is ensure that all API callbacks are executed asynchronously instead of just those that are inherently async. Without the setImmediate() calls, caller-provided callbacks will be executed before the rest of the calling function.

E.g.

functionfoo(){getInfo(function(err,info){console.log("1");});console.log("2");}

Given that getInfo presents itself as an asynchronous function (and often is), the expected output is:

2
1

However, if getInfo is implemented synchronously without setImmediate, the output is actually:

1
2

I remember reading a blog post that drives the point home a bit more effectively, but I can't find it.

[yhahn]

@mojodna yes I'm familiar with what this is doing. However is this a new convention throughout node core? As far as I know just because a function takes a callback does not mean that it is implied the callback will be called in the next tick.

[sethfitz]

Not that I know of (though it is a common use of setImmediate that I've seen); it's just applying consistent rules to the implementation. It's not implied that the callback won't be called in the next tick either, but to have some arguments result in one behavior and others result in the other is just asking to confuse people.

[yhahn]

Cool, help me understand what actual concrete things this will solve for you... I have run into this before but usually consider it a failure of my own expectations -- passing a callback doesn't promise anything about what tick/call order is about to happen next in my mind, and if I need an explicit call order I implement it from the calling code.

[sethfitz]

Nothing, honestly. I was in there working on #24 (and #22) and figured I'd straighten up while I was at it.

I'd consider it a failure of the libraries you're using, not your own. Coding defensively by choice / habit is one thing, coding defensively by necessity is unfortunate. I generally assume "future", but it's rare that I actually rely on that behavior (and when I do, I suppose I also fall back to being explicit).

[springmeyer]

(Sorry, the link to support this this isn't handy.)

Saw kelektiv/node.bcrypt.js#264 go by, which provides a bunch of supporting links.

[yhahn]

y closing -- this is not a consistent expectation in the node ecosystem.