-
Notifications
You must be signed in to change notification settings - Fork 404
introduce Command.Parse(CommandLineConfiguration) #2062
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
Conversation
…d setting it as a Parent of given Argument
…setting it as a Parent of given Argument
…ser instance anymore
…ndLineBuilder itself, make it partial class to reduce diff size
public void SetupParser() | ||
{ | ||
SetupRootCommand(); | ||
_testParser = new Parser(_rootCommand); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Parser is now static, we can't benchmark it's creation ;)
/// Provides extension methods for <see cref="CommandLineBuilder"/>. | ||
/// </summary> | ||
public static class CommandLineBuilderExtensions | ||
public partial class CommandLineBuilder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to keep the diff smaller, I've decided to make the class partial rather than moving all the code to CommandLineBuilder
@@ -12,10 +12,10 @@ namespace System.CommandLine | |||
/// <summary> | |||
/// Enables composition of command line configurations. | |||
/// </summary> | |||
public class CommandLineBuilder | |||
public partial class CommandLineBuilder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this type was building a parser, but it was called CommandLineBuilder
. Now it could be called CommandLineConfigurationBuilder
, but this name is long and I expect that in the near future we are going to start using Cli
name prefixes for types, so I've decided to keep the name for now.
CommandLineConfiguration => CliConfiguration
CommandLineBuilder => CliConfigurationBuilder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our hope is to remove the CommandLineBuilder
class in any case, yes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our hope is to remove the CommandLineBuilder class in any case, yes?
The tricky part is to expose only properties, so we can configure everything by just using the setters and not needing fluent APIs. I am currently working on implementing Directive
symbol and it looks very promising in that regard.
src/System.CommandLine.Benchmarks/CommandLine/Perf_Parser_NestedCommands.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Kevin B <Keboo@users.noreply.github.com>
* use name "arguments" rather than "args" * don't accept null * accept IReadOnlyList rather than array
# Conflicts: # src/System.CommandLine.ApiCompatibility.Tests/ApiCompatibilityApprovalTests.System_CommandLine_api_is_not_changed.approved.txt # src/System.CommandLine.Tests/Invocation/InvocationPipelineTests.cs # src/System.CommandLine.Tests/ResourceLocalizationTests.cs # src/System.CommandLine/Builder/CommandLineBuilder.cs # src/System.CommandLine/Builder/CommandLineBuilderExtensions.cs # src/System.CommandLine/Invocation/InvocationContext.cs
Initially, I just wanted to extend
Symbol
withParse(string[], CommandLineConfiguration)
.I've realized that the existing
Argument.Parse
andOption.Parse
methods have side effects, namely creating aRootCommand
for given option/argument which sets the Symbol parent:command-line-api/src/System.CommandLine/SymbolExtensions.cs
Lines 86 to 88 in 704e640
command-line-api/src/System.CommandLine/ChildList.cs
Lines 37 to 41 in 6462288
Since these methods were used only for testing and can be very easily replaced with explicit one liner I've decided to remove them:
After doing that I've just moved
CommandExtensions.Parse
toCommand
to make it easier to discover (and follow BCL guidelines).When I wanted to make
Parser
a static class, I've realized that we had two different default configs:command-line-api/src/System.CommandLine/SymbolExtensions.cs
Line 41 in 704e640
command-line-api/src/System.CommandLine/SymbolExtensions.cs
Line 54 in 704e640
I've decided to use the same default config everywhere (the one that uses
UseDefaults
) andCompletionTests
tests started failing, as they were not expecting the suggestions to contain--help
and--version
(global options added by default in the default config). I've just fixed the tests by passing the "simple" config in explicit way.Another change that I've made was making
Command
a mandatory argument forCommandLineBuilder
ctor:command-line-api/src/System.CommandLine/Builder/CommandLineBuilder.cs
Lines 26 to 28 in 704e640
I did that because it was making it easy to fall into a trap of not passing the existing command to the ctor and ending up with "disconnected" root command being used by the config:
Since
Command.Parse
acceptsCommandLineConfiguration
and the class is not mutable yet, I wanted to make it easier to discover the builder type, so I've added:I've also moved a bunch of extension methods to the types they were extending (BCL guideline).
I hope that all these changes are going to improve the discoverability of:
fixes #2054
makes a progress toward #2057