Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Square with the promise of being an async API #23

Closed
wants to merge 1 commit into from

Conversation

mojodna
Copy link
Contributor

@mojodna mojodna commented Jul 15, 2014

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

@yhahn
Copy link
Member

yhahn commented Jul 15, 2014

Heh is this a new convention.

@mojodna
Copy link
Contributor Author

mojodna commented Jul 15, 2014

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.

function foo() {
  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
Copy link
Member

yhahn commented Jul 15, 2014

@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.

@mojodna
Copy link
Contributor Author

mojodna commented Jul 15, 2014

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
Copy link
Member

yhahn commented Jul 15, 2014

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.

@mojodna
Copy link
Contributor Author

mojodna commented Jul 15, 2014

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
Copy link

(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
Copy link
Member

yhahn commented Dec 24, 2014

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

@yhahn yhahn closed this Dec 24, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants