-
Notifications
You must be signed in to change notification settings - Fork 19
Include default values in the spec #34
As brought up in #16 it would be useful to include the default values for non-required fields in the spec.
I think for most fields some general rules can be formulated, but especially the arity field should have an non-null default
General Rules
- Boolean fields default to
false - Array fields default to an empty array
- Object fields default to a object filled with the default values of the specified type (i.e. the
conventionsfield in the Document object defaults to a Conventions object with it's default values)
Argument Object / arity
I think in most CLIs, the default case for arguments is that an argument is optional and may appear once, so a sensible default for an argument's arity may be
{
"minimum": 0,
"maximum": 1
}All reactions
Added in #59
Replies: 3 comments 3 replies
An 'option' appearing once is IMO a bit up for discussion though - it's quite common for repeated uses of an option to either
- accrue/increase some logical counter (as in POSIX-style
-v/-vv/-vvvvvvvscenarios) - be overwritten in a 'last one wins' manner (as in
--foo a --foo b=>--foo beffectively)
and I'm sure there are other strategies that I'm missing as well. How do these modalities interact with Arity?
All reactions
In my understanding, the arity field is currently only there for arguments but not for options.
However, I think it makes sense to have an arity on the Option object as well and I think there would need to be different default arities for options vs arguments.
I've opened up a separate discussion regarding the Option arity here: #35
All reactions
I don't think arity on the Option Object will do any good here since they only will take the values 0:1, 1:1, or 1:*.
I'm also starting to think that perhaps having an argument property on the Option Object is the wrong way to go here as well, since it makes things a bit difficult to understand and follow, and not sure if it really helps any use cases. I will open a new discussion around that.
Scenarios
The scenarios I can think of (that @baronfel mentioned as well) is:
- Only one option with the same name is allowed per command.
- Repeatable use of an option is allowed. If the option only takes one value (ex.
arityis0:1or1:1) then:- That's an error.
- The last one wins.
- The first one wins. Never seen this personally, but might exist.
Special case
Then it's the scenario with the -v, -vv, and -vvv which accrue/increase some logical counter that @baronfel mentioned,
but I would be OK not supporting this initially in the spec.
All reactions
|
Here's a proposal for default values: Document Object
CliInfo Object
Conventions Object
Contact Object
License Object
Command Object
Argument Object
Option Object
Arity Object
ExitCode Object
Metadata Object
|
All reactions
Created issue: #58
All reactions
Added in #59