Closed eapyl closed 5 years ago
I think this change means that many (all?) existing uses of DefaultValue
now have to use ForcedDefaultValue
, which caused me quite a lot of confusion when updating the version of CommandLineParser just now. I can raise an issue with full details and code if you need it.
Sorry for the confusion. Please raise an issue with the usage differences for before/after this code.
I have the same issue. However, my understanding is that it's not really a bug, but rather an unconscious and unadvertised breaking change.
Also could not find anything about ForceDefaultValue
in the documentation.
Basically, i had this code :
[ValueArgument(
typeof(int),
"connectiontimeout",
DefaultValue = 5,
Description = "The time to wait for a connection to open.",
FullDescription = "The time (in seconds) to wait for a connection to open. The default value is 5 seconds.",
Example = "15")]
public int ConnectionTimeout { get; set; }
This code would behave like this :
Now with the introduction of ForceDefaultValue
the code behaves like :
This is how it broke my application.
My understanding, is that there is a change of semantic of DefaultValue
.
It was the default value for both the lack of passed parameter and the lack of value for a passed parameter.
It seems to me, now, those 2 cases are split :
ForceDefaultValue
is used for the lack of passed parameterDefaultValue
is used for the lack of value for a passed parameterTherefore if I understand correcly, in the latest version, I to change my code to :
[ValueArgument(
typeof(int),
"connectiontimeout",
DefaultValue = 5,
ForcedDefaultValue = 5,
Description = "The time to wait for a connection to open.",
FullDescription = "The time (in seconds) to wait for a connection to open. The default value is 5 seconds.",
Example = "15")]
public int ConnectionTimeout { get; set; }
That is, for ValueArgument, if I want to keep the old behavior, wherever I have DefaultValue
, I now have to also add ForcedDefaultValue
.
Can you confirm ?
I'm not raising an issue because I think there's no (simple) going back except reverting the new feature. It would have been nice to document the change and change the major version number of the package though.
Thank you for this information. I will try to understand and investigate the code and see if I can bring the old behaviour back.
I proposed a fix in PR #68
As it is described in #55