-
Notifications
You must be signed in to change notification settings - Fork 418
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
API change: parse results for subcommands #134
Comments
Initial thoughts for a solution:
Option 1 is simple but a bit cumbersome to use. Client code always needs to call One idea for option 2:
|
What if the
|
Thought about it some more and I'm now leaning towards simply returning a
Showing usage help then becomes very easy:
Generally I prefer returning the full information in the result to storing some temporary information in the CommandLine instance: conceivably the same |
Fair enough. Just a comment of method name, I found |
I hadn't realized, thanks for pointing that out. I like There is some potential confusion with
|
IMO Just my 2 cents ;) |
Sorry, I only just saw your comment. I think #127 has unearthed a number of hidden deficiencies, I'm quite happy with all these changes. |
Problem with Usage Help for Subcommands
Adding support for nested subcommands (#127) highlighted a problem with the
CommandLine::parse(String...)
method: it currently returns a List with the annotated objects that were registered as subcommands.This is a problem because without the
CommandLine
objects associated with these annotated objects, the usage help cannot list the subcommands registered on thoseCommandLine
instances...Example: suppose we have a subcommand hierarchy like this:
Suppose the user asked for help on subcommand
cmd3
:In the current picocli API, this is hard to implement since the parsing result does not give a reference to the CommandLine instance that the nested subcommands are registered. It returns a list of annotated objects instead of a list of CommandLine objects:
The parse result should allow the client code to get a reference to the
CommandLine
object associated with the parsed subcommand.The text was updated successfully, but these errors were encountered: