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

Make Option.env() behave as a getter when called with no arguments #1971

Closed
wants to merge 1 commit into from

Conversation

aweebit
Copy link
Contributor

@aweebit aweebit commented Aug 15, 2023

Another tiny enhancement third-party libraries could benefit from (like #1970).

Problem

I had to use the internal Option.envVar to build informative error messages in the async-commander library I am currently working on.

Solution

Make Option.env() return the value of the variable when it is called with no parameters.

ChangeLog

Added

  • Option.env() now returns the previously provided environment variable name when called with no argument

@aweebit aweebit changed the title Make Option.env() behave as a getter when no name is supplied Make Option.env() behave as a getter when called with no arguments Aug 15, 2023
@shadowspawn
Copy link
Collaborator

shadowspawn commented Aug 15, 2023

Unless the property name starts with an underscore, it is public. e.g. option.public, option._private So it is fine to access option.envVar.

Option was once a simple prototype class with all public properties. As new features were added and Option became more full-featured, the existing properties were preserved and the all-public pattern was continued. (Which does lead to some naming gymnastics to have both a property and a chaining setter.)

@aweebit
Copy link
Contributor Author

aweebit commented Aug 15, 2023

Unless the property name starts with an underscore, it is public. e.g. option.public, option._private So it is fine to access option.envVar.

It is not included in the typings, though, that's why I though it was private. Had to include it in the manually augmented module declaration along with Command._args because of that, see typings/commander.d.ts.

So do you think it should be added to the library's type declarations instead? Or can we also keep the change I suggest here? It's not always easy to remember which methods are setter-only and which can also be used as getters. Since there is no other meaningful interpretation for an Option.env() call with no arguments, I think it's okay if we keep it.

@shadowspawn
Copy link
Collaborator

shadowspawn commented Aug 15, 2023

It is not included in the typings, though, that's why I though it was private.

Oops, that explains it, I had wondered why you hadn't just used the property!

So do you think it should be added to the library's type declarations instead?

Yes.

Or can we also keep the change I suggest here?

No. Option does not have any properties using the overloaded getter/setter pattern that is used quite a bit in Command.

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.

None yet

2 participants