-
Notifications
You must be signed in to change notification settings - Fork 10
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
Behaviour for withValue --foo followed by --bar ? #25
Comments
On the command line, In other words, without the equals sign, I think it must be undefined; with, it must be the empty string. I also agree that valid dashed things shouldn't be eligible to be values, eg am unquoted |
As @ljharb noted,
Setting the value as an empty string infers it's a "truthy" value, which sort of goes against the idea of "bringing your own validation" (which, imo, should be a goal of ours if we want to minimize critics of when/if/how we determine those values). For me, the following examples illustrate what my ultimate expectations would be if we were to properly disassociate the existence of, vs. value of, flags... (ref. to my comment over here: #24 (comment) on the differentiation for "existence of" vs. "value of") parseArgs(['--foo', '--bar'])
/*
{
flags: { foo: true, bar: true },
values { },
positionals: []
}
*/
parseArgs(['--foo', '--bar'], { withValue: ['foo'] })
/*
{
flags: { foo: true, bar: true },
values { foo: undefined },
positionals: []
}
*/
parseArgs(['--foo=', '--bar=""'], { withValue: ['foo'] })
/*
{
flags: { foo: true, bar: true },
values { foo: undefined },
positionals: []
}
*/
parseArgs(['--foo=', '--bar=""'], { withValue: ['foo', 'bar'] })
/*
{
flags: { foo: true, bar: true },
values { foo: undefined, bar: '' },
positionals: []
}
*/
parseArgs(['--foo=', 'baz', '--bar=""'], { withValue: ['foo', 'bar'] })
/*
{
flags: { foo: true, bar: true },
values { foo: 'baz', bar: '' },
positionals: []
}
*/
parseArgs(['--foo=', 'baz'], { withValue: ['foo', 'bar'] })
/*
{
flags: { foo: true, bar: false },
values { foo: 'baz', bar: undefined },
positionals: []
}
*/
parseArgs(['--foo=', 'baz', '--bar=false'], { withValue: ['foo', 'bar'] })
/*
{
flags: { foo: true, bar: true },
values { foo: 'baz', bar: 'false' },
positionals: []
}
*/ |
Disagree, I recommend empty string is implied by
|
Disagree, empty string as before but fun speech marks case:
I think the bar value is the string following the equals, which because it is passed in code is actually two double speech marks. I know this may not have been intended, but I think it is nice it came up. I suggest we do not do any fancy speech mark processing, KISS (Keep It Simple Stupid). Now if |
Disagree, if you use the equals then the value is what is in the same argument after the equals.
|
Recapping the original question:
Current feedback: Jordan and Darcy and I all happy with status quo. |
This comment has been minimized.
This comment has been minimized.
I changed my mind! (Actually the end result may be the same, but my reasoning is now different.) Short version: Looks like a flag, stored like a flag. Assuming we stop storing
Long version I initially felt it was wrong to store the same results as a flag, because we knew we were expecting a value. But the knowledge we were expecting a value is external to the results, we still know that whatever we store. If Treating the result like a flag was used has a nice simple symmetry:
Looks like a flag, stored like a flag. Looks like a value, stored like a value. |
Here is a run through of my proposed behaviours for an option listed in The naming and output I have used here is based on the "existence" pattern per: #38 (comment)
Remember, only the first usages are consistent with a flag which takes a value. The later cases are misuse which can be detected by the client if desired.
[Edit: added missing |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
OK, but still, |
Why is omitting the equal sign incorrect? |
I think of It is widely accepted in the parsers consulted in the initial tooling proposal. See the column with the |
That's the convention (from GNU and/or POSIX, i think). I realize it is widely accepted, but that doesn't mean it's the proper default. At the very least, both "modes" should be configurable - requiring the equals sign, or allowing it to be omitted. |
Why configurable? An end-user always using the form The man pages for
Do you have an example of a common utility that supports long options and does not support |
The four conventions that I see commonly supported for supplying a value for an option which requires a value are:
|
I explicitly want to require use of the To be fair, the more i search around, the more I'm horrified to find that everything seems to be loosey-goosey with this, and allow the |
The help output of |
there's always a counterexample :-) sadly i think i'm convinced that the default needs to allow omitting the |
Ideally we could just have a strong opinion that
This all looks great to me except the last option which I would expect to be expanded to |
I disagree, I do not think there needs to be way to enforce it in this library. I suggest we discuss that in a separate issue if desired. This issue is intimidatingly long, but great to uncover some more assumptions! |
@shadowspawn it's fine if the validation part is done on my own, but how can it be possible for me to enforce it with this library? Filed #52 for this. |
I wasn't clear on what issues I was uncovering when I opened this issue, so got interesting wide discussion. 😅 The The result of parsing a
|
I am working through some of the special cases during a refactor of the results code.
This is a case where the parser could behave two ways. The
--foo
option is expecting a value, there is an argument available, but the argument looks like an option.The current implementation is that
foo
gets the valueundefined
, and--bar
is seen as a flag.--bar
as a flag rather than the value is the least surprising behaviour, so just confirming that this is as intended and/or expected by others?foo
was an empty string rather thanundefined
? This might be more consistent from a typing point of view. I don't have a wrong preference.Current behaviour, assuming flags are stored in flags and values are stored in values:
If the user wants the
--bar
to be the value then they can achieve this with--foo=--bar
.For comparison:
foo
configured to be a "string" it gets an empty string as value, and--bar
is parsed as a flag.Added TL;DR proposal: #25 (comment)
The text was updated successfully, but these errors were encountered: