Document boolean flags by presence

[sixolet]

Add documentation that boolean flags should be specified by flag presence.

This is mutally exclusive with #284 .

Vote by thumbs up reaction emoji. Winner gets merged.

[rhuss]

Actually, both variations (with and without --no) should be present in this case, regardless of the default value (using the variant that corresponds to the default value should be possible, too). In this example, e.g. --generate-name and --no-generate-name should be both available all the time (corresponding --generate-name=true and --generate-name=false).

The reason why I prefer this variant is:

• There is no ambiguity what should be used as boolean value ("true", "yes" and "on" are commonly used as such values), where "true" is probably mostly accustomed for programmers (maybe not so much users of kn ?)
• It's shorter without specifying the value
• It stands in the tradition of GNU getopts (sometimes you see the variation --with- and --no- for true and false)
• Many boolean options are modelled like this in Unix (they are called 'flags' in this case. Eg.: ls -l)
• We already use that style e.g. for kn --help (or would we like to switch to kn --help=true ?). Other examples: kn service create --force or kn service create --async would have change to kn service create --force=true and kn service create --async=true (or maybe in the latter case --sync=false)
• For consistencies reasons we would always have to require options with values then, which might lead to an unnecessarily bloated UI (because you can't use simple flags anymore).

[toVersus]

Actually, both variations (with and without --no) should be present in this case, regardless of the default value (using the variant that corresponds to the default value should be possible, too).

I have the same feeling.

[cppforlife]

just noticed your statement here:

We already use that style e.g. for kn --help (or would we like to switch to kn --help=true ?). Other examples: kn service create --force or kn service create --async would have change to kn service create --force=true and kn service create --async=true (or maybe in the latter case --sync=false)

--help continues to work as cobra defaults it to mean true. so full form --flag=false is only necessary when turning things off.

[rhuss]

@cppforlife Have you tried kn --help=false ? My bad, it works as expected (no arg == help). You can use kn service list --help=false, too.

[maximilien]

/approve

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: maximilien, sixolet

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [maximilien,sixolet]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[duglin]

I think the most compelling argument made was:

It stands in the tradition of GNU getopts (sometimes you see the variation --with- and --no- for true and false)
Many boolean options are modelled like this in Unix (they are called 'flags' in this case)

The use of ..=true and ..=false always felt a bit odd to me.

Either PR can work though... my only really BIG sore point is if we allow --no-xxx=false. The double negative is just painful for people. So if we support ..=BOOL then we should never allow the name to start with no.