Summary
Adjust CLI boolean switches to clearly allow both true and false.
Note: this should be implemented soon to prevent future code churn.
Motivation
The example -rest.disabled is unclear as it seems like it should require the value true or false like dab init -rest.disabled true; however, the behavior is actually like this: its presence alone is the value true & the value false is only possible when the switch is not present. This is quite unintuitive and prone to error for developers who are not meticulously referencing our documentation. This original approach was loosely based on alignment with the AZ CLI but proves far too unintuitive to leave like it is. See below.
Old behavior
dab init -rest.disabled As stated above, the presence of the switch is a true value for the "negative" switch. The false value of this "negative switch, is to omit it from the CLI op.
New behavior
dab init -rest.enabled false As stated above, the positive switch receives either a true or false value to indicate the operation. It has defaults, but its omission is not necessary to set a specific value. It can set either true or false explicitly or fall back to the default in omission. In the case of some CLI switches, there may not be a default value, making its presence required.
Important notes:
- The original "negative" switch remains unchanged but is deprecated. The reason for this is only for backwards compatibility with the old behavior as we move forward. All "negative" switches will also be removed from any documentation & samples to discourage use going forward. We can discuss breaking changes before GA for "negative" switches.
- The new "positive" switch is not boolean, but a
true/false enum. The reason for this is to overcome any limitations in the args library we are using. It will appear to be a boolean to the developer. As a result, the enum will simulate boolean behavior of passing true and false.
- Going forward, all boolean-like switches in the CLI will use this approach - both avoiding any "negative" switches and simulating boolean ops with a
true/false enum.
Summary
Adjust CLI boolean switches to clearly allow both
trueandfalse.Motivation
The example
-rest.disabledis unclear as it seems like it should require the valuetrueorfalselikedab init -rest.disabled true; however, the behavior is actually like this: its presence alone is the valuetrue& the valuefalseis only possible when the switch is not present. This is quite unintuitive and prone to error for developers who are not meticulously referencing our documentation. This original approach was loosely based on alignment with the AZ CLI but proves far too unintuitive to leave like it is. See below.Old behavior
dab init -rest.disabledAs stated above, the presence of the switch is atruevalue for the "negative" switch. Thefalsevalue of this "negative switch, is to omit it from the CLI op.New behavior
dab init -rest.enabled falseAs stated above, the positive switch receives either atrueorfalsevalue to indicate the operation. It has defaults, but its omission is not necessary to set a specific value. It can set eithertrueorfalseexplicitly or fall back to the default in omission. In the case of some CLI switches, there may not be a default value, making its presence required.Important notes:
true/falseenum. The reason for this is to overcome any limitations in the args library we are using. It will appear to be a boolean to the developer. As a result, the enum will simulate boolean behavior of passingtrueandfalse.true/falseenum.