-
Notifications
You must be signed in to change notification settings - Fork 61
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
args: default negatable to false #26
Comments
<img src="https://avatars.githubusercontent.com/u/5449880?v=3" align="left" width="48" height="48"hspace="10"> Comment by iposva-google In my opinion why you want negatable boolean options is so that you can easily experiment on the command line without having to remove the flag by just adding the "no-" to form a --no-xyz. It is especially useful if you want to call out that a flag is off when comparing two outcomes. Also the premise that the default is set to false in general is not entirely correct. An example: The --inline flag should probably default to true in a compiler, with the option to turn off inlining if needed. A false default would mean that you would have the awkwardly named flag --dont_inline and the even more strange use within the code. Added Area-Pkg, Library-Args, Triaged labels. |
<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan Thanks, I wasn't aware of the use case to quickly switch between --foo and My main gripe though is that since I get a negated version by default, it's |
<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan FWIW, I looked up chrome's command line flags (since it has a ton of them): http://peter.sh/experiments/chromium-command-line-switches/ and they seem to follow the practice of only including --no-foo, instead of |
<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan Also forgot to mention that multiple flags are also often used in an enum https://github.com/dart-lang/spark/blob/master/ide/tool/test_runner.dart#L129 .. and these type of flags are never negatable. |
<img src="https://avatars.githubusercontent.com/u/3276024?v=3" align="left" width="48" height="48"hspace="10"> Comment by anders-sandholm Removed Library-Args label. |
<img src="https://avatars.githubusercontent.com/u/46275?v=3" align="left" width="48" height="48"hspace="10"> Comment by munificent Yeah, I agree with you Sean. I thought defaulting to allow negation would make things more flexible, but in practice it feels like the wrong default. Alas, it would be a breaking change. I'll probably do it at some point, but I'm going to sit on it for a while. |
Another reason to have negatable flags is if the tool supports saving defaults (e.g. in a .xxxrc file). If you save a positive value, you need a way to negate it on the command line. For this reason, I think the real solution here is to make addCommand support taking commands that start with Though if |
Can you expand on this? I'm not 100% sure what you mean. |
When you say "foo --version", you're really saying "foo version", that is, you're trying to run the "version" subcommand of "foo". |
<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="96" height="96"hspace="10"> Issue by seaneagan
Originally opened as dart-lang/sdk#16022
I can't prove this, but I feel like non-negatable is more common.
For example, --help, --verbose, --quiet, --version are all non-negatable. Also, since flags should generally default to false, specifying --no-foo is redundant. I would prefer to explicitly ask for this feature when I need it, but I'm not sure when that would be.
The text was updated successfully, but these errors were encountered: