[CLI-340] Add CommandLine.getParsedOptionValues() #334
Conversation
There was a problem hiding this comment.
Hello @Claudenw
- See exception management comment (rebase on git master svp)
- For all Javadoc of new methods: Can the method return null? If so, when? What happens if the option does not exist?
- Are all these APIs really needed? Couldn't we just add a minimal set following the YAGNI principle. Not my use case, so you tell me ;-)
| @@ -691,6 +692,203 @@ public <T> T getParsedOptionValue(final String opt, final T defaultValue) throws | |||
| return getParsedOptionValue(resolveOption(opt), defaultValue); | |||
| } | |||
|
|
|||
| /** | |||
| * Gets a version of this {@code Option} converted to an array of a particular type. | |||
| * | |||
There was a problem hiding this comment.
Can the method return null? If so, when? What happens if the option does not exist?
There was a problem hiding this comment.
As with all the value getter methods if the option is not in the command line null is returned unless the default value is defined.
There was a problem hiding this comment.
OK, then please update the Javadoc instead of writing it up here ;-)
| * @see PatternOptionBuilder | ||
| * @since 1.10.0 | ||
| */ | ||
| public <T> T[] getParsedOptionValues(final char opt) throws ParseException { |
There was a problem hiding this comment.
No need to abbreviate IMO: opt -> option. Also, using opt in Javadoc makes for awkward reading.
There was a problem hiding this comment.
I am following the pattern used in the class. Methods from earlier versions used opt, I elected to do the same.
There was a problem hiding this comment.
Well, it's slightly awkward (to me) to read "@param opt the name of the option." If 'opt' is the name, then why not call it 'name' or 'optionName'? Might as well do the best we can for new code. We can fix the rest separately if you want or do it all in this PR since.
I updated the javadoc to reflect the null or default value return as appropriate. I also updated the javadoc for the
There are all here because they follow the same pattern as getParsedOptionValue() methods. I think they need to be here because V1 supports all those access methods for getOptionValue, getParsedOptionValue, and getOptionValues. I think that in V2 I would limit each set to 4 implementations getOptionValue(Option), getOptionValue(OptionGroup), getOptionValue(Option, default), and getOptionValue(OptionGroup, default). The char and String versions are just fluff. I think that since the application has to create the Options it can keep them around and use them directly without referring to the char or String versions keys. |
| @@ -691,6 +692,203 @@ public <T> T getParsedOptionValue(final String opt, final T defaultValue) throws | |||
| return getParsedOptionValue(resolveOption(opt), defaultValue); | |||
| } | |||
|
|
|||
| /** | |||
| * Gets a version of this {@code Option} converted to an array of a particular type. | |||
| * | |||
There was a problem hiding this comment.
OK, then please update the Javadoc instead of writing it up here ;-)
| * @see PatternOptionBuilder | ||
| * @since 1.10.0 | ||
| */ | ||
| public <T> T[] getParsedOptionValues(final char opt) throws ParseException { |
There was a problem hiding this comment.
Well, it's slightly awkward (to me) to read "@param opt the name of the option." If 'opt' is the name, then why not call it 'name' or 'optionName'? Might as well do the best we can for new code. We can fix the rest separately if you want or do it all in this PR since.
Claudenw
force-pushed
the
CLI-340_add_getParsedOptionValues
branch
from
d1df605 to
a55b1ff
Compare
|
If you want me to change "opt" to "option" throughout the CommandLine class I'll do it. But having some method params be "opt" and others be "option" seems sloppy. |
Hi @Claudenw |
|
@garydgregory Let's fix the naming in V2. |
garydgregory
changed the title
garydgregory
changed the title
garydgregory
changed the title
Fix for CLI-340 (add
getParsedOptionValues())fix a minor formatting issue in Help javadoc.