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

programmatic command registration: option name needs to match parameter name #1042

Open
georgmittendorfer opened this issue Apr 13, 2024 · 1 comment
Labels
type/enhancement Is an enhancement request

Comments

@georgmittendorfer
Copy link

georgmittendorfer commented Apr 13, 2024

Current behaviour:

Currently the following registration (assuming there is some pojo named command)

CommandRegistration.builder()
                .command("some-command")
                .withTarget().method(command, "add").and()
                .withOption().longNames("identity").and()
                .build();

matches the method

public String add(String identity) { ... }

but it would not match the method

public String add(String id) { ... }

That means that the option name needs to be equal to the parameter name but there is no reason for this as it is the only parameter. That is not very intuitive and it is not documented anywhere (at least I didn't find it).

Expected behaviour:

  • When target method only has one parameter it should match independent of the option name.
  • When target method only has one parameter it should even match given input without option name or there should be an error message that the option is missing (currently it simply passes null even if the option is required).
  • It should be documented somewhere what the requirements for option matching are.
@github-actions github-actions bot added the status/need-triage Team needs to triage and take a first look label Apr 13, 2024
@jvalkeal
Copy link
Contributor

Thanks for comments. This type of registration was originally added to support registering annotated methods and its "magical" behaviour was somewhat baked inside logic discovering those methods. I think you're a first one asking how this behaves so point taken as It wasn't intentionally left hard to use.

@jvalkeal jvalkeal added type/enhancement Is an enhancement request and removed status/need-triage Team needs to triage and take a first look labels Apr 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement Is an enhancement request
Projects
None yet
Development

No branches or pull requests

2 participants