Skip to content
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

Fix for CLI-340 #334

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

Claudenw
Copy link
Contributor

Fix for CLI-340 (add getParsedOptionValues())
fix a minor formatting issue in Help javadoc.

@Claudenw Claudenw self-assigned this Nov 12, 2024
@Claudenw Claudenw marked this pull request as ready for review November 12, 2024 17:42
Copy link
Member

@garydgregory garydgregory left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ;-)

result[i] = clazz.cast(option.getConverter().apply(values[i]));
}
return result;
} catch (Throwable t) {
Copy link
Member

@garydgregory garydgregory Nov 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Catching Throwable is a bit of an anti-pattern here IMO because you certainly don't want to demote Errors as ParseExceptions

You should catch more specific exceptions, even if means catching all of Exception.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, I was following the pattern from getParsedValue(). I will fix it there as well, but since the Converter throws Throwable we have to deal with it as a Throwable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not anymore ;-) Please rebase git on master (my comment from the preview review).

@@ -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.
*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can the method return null? If so, when? What happens if the option does not exist?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to abbreviate IMO: opt -> option. Also, using opt in Javadoc makes for awkward reading.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am following the pattern used in the class. Methods from earlier versions used opt, I elected to do the same.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

Claudenw commented Nov 12, 2024

For all Javadoc of new methods: Can the method return null? If so, when? What happens if the option does not exist?

I updated the javadoc to reflect the null or default value return as appropriate. I also updated the javadoc for the getParsedOptionValue() methods.

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 ;-)

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.

Copy link
Member

@garydgregory garydgregory left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Claudenw

I've added 3 comments.

result[i] = clazz.cast(option.getConverter().apply(values[i]));
}
return result;
} catch (Throwable t) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not anymore ;-) Please rebase git on master (my comment from the preview review).

@@ -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.
*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

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.

@garydgregory
Copy link
Member

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
I don't want to give you more work so I'll leave it up to you and it could be done later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants