Symbol.Description does not need to be virtual #2045
Conversation
…iption to ctor when creating every Symbol the affected ctors belonged to internal types
| @@ -316,7 +316,7 @@ void Default(Exception exception, InvocationContext context) | |||
| /// <returns>The same instance of <see cref="CommandLineBuilder"/>.</returns> | |||
| public static CommandLineBuilder UseHelp(this CommandLineBuilder builder, int? maxWidth = null) | |||
| { | |||
| return builder.UseHelp(new HelpOption(() => builder.LocalizationResources), maxWidth); | |||
| return builder.UseHelp(new HelpOption(builder.LocalizationResources), maxWidth); | |||
There was a problem hiding this comment.
If the application first calls CommandLineBuilderExtensions.UseDefaults and then calls CommandLineBuilderExtensions.UseLocalizationResources, this PR will prevent the help from using the application-specified resources.
There was a problem hiding this comment.
I suppose the application could fix that by calling CommandLineBuilderExtensions.UseLocalizationResources before CommandLineBuilderExtensions.UseDefaults. But if there is such a constraint, then it should be mentioned in the documentation of CommandLineBuilderExtensions.UseLocalizationResources.
There was a problem hiding this comment.
That is correct, but we are soon going to make LocalizationResources internal and never expose it again (#2041).
There was a problem hiding this comment.
#1915 still "needs discussion".
There was a problem hiding this comment.
I had meant to comment on this last week. I've updated #1915 with some thoughts on this.
Symbol.Description does not need to be virtual, we can pass the description to ctor when creating every Symbol
the affected ctors belonged to internal types