Skip to content
This repository has been archived by the owner on Jun 20, 2023. It is now read-only.

why .disposeAsync and not .dispose? #13

Open
ljharb opened this issue Feb 12, 2023 · 3 comments
Open

why .disposeAsync and not .dispose? #13

ljharb opened this issue Feb 12, 2023 · 3 comments

Comments

@ljharb
Copy link
Member

ljharb commented Feb 12, 2023

The "async" suffix might make sense when the two methods are alongside each other, but this is already an AsyncDisposableStack instance. Why not just use .dispose?

@rbuckton
Copy link
Collaborator

rbuckton commented Feb 12, 2023

I'm generally of the opinion that most async operations in a standard library should be named such, even when there isn't a need to differentiate. The exception to that is methods on something like Promise, where it's usually obvious such operations are async. There are far too many API methods in Nodejs and in the DOM that don't follow that pattern, and I've often seen them used incorrectly under the assumption that the methods did something synchronously instead, leading to race conditions.

More clearly describing the behavior is helpful not only to code writers, but to code readers and reviewers. If we only used dispose(), it's far harder for a reviewer to spot the missing await in something like this:

async function shutdown(stack) {
  ... 
  stack.dispose();
  ... 
} 

Also, naming it disposeAsync here more clearly indicates that it is the only async operation on the object. use, et al., are sync operations.

@ljharb
Copy link
Member Author

ljharb commented Feb 12, 2023

Other than Array.fromAsync (which isn't stage 4 yet), we don't have such a precedent in the language.

I see your point about differentiating from the other operations which are sync, but i'm not sure if using a form of hungarian notation is a sufficient substitute for reading the docs, or using types.

@rbuckton
Copy link
Collaborator

This kind of differentiation is fairly common in many languages, with or without type systems. The proposed Atomics.waitAsync also follows this naming convention.

I'm stating that we should establish such a precedent in the language. Potentially even a formalized API design guideline for built-ins.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants