Unintuitive `ValueObject` behavior about docopt.net HOT 6 CLOSED

IsInt should really be named IsOfTypeInt because I really mean it to test for type compatibility (straight python code translation) rather than to confirm that a value can be potentially treated as an integer.

So how about implementing IsInt with Int32.TryParse() the way you describe and redirect the current internal usages of IsInt to a IsOfTypeInt method? I wonder if AsInt should not be revisited as well?

If IsInt was directly implemented using Int32.TryParse() the test LanguageAgnosticTests.Test_104 would be broken because "--speed=20" would be wrongly be considered of type int.

Regarding the constructor, ValueObject is known to take arguments of type int in the context of incremented flags as produced by:

Usage: prog [-vv]

See CountMultipleFlagsTests.

from docopt.net.

Okay. I can propose a PR with something like that. But is there any value to having IsOfTypeInt exposed to consumers of the library? Your description of it makes it sound like it is used only internally. If that's so, I'd make it internal.

Relatedly, there is an IsString property. This property is implemented like IsOfTypeString. If we create IsInt with this implementation, should it be permissible that something that has IsInt = true also have IsString = true? On the one hand, it can be used like a string. On the other hand, one would think these properties would be mutually exclusive. I can see a good argument for both sides.

from docopt.net.

Agreed, internal it should be. Sounds to me like IsOfTypeInt and IsOfTypeString should be mutually exclusive. Have a look at the Match method in LeafPattern.—
Sent from Mailbox for iPad

On Wed, Dec 18, 2013 at 6:02 PM, Kyle Peter Fritz
[email protected] wrote:

Okay. I can propose a PR with something like that. But is there any value to having IsOfTypeInt exposed to consumers of the library? Your description of it makes it sound like it is used only internally. If that's so, I'd make it internal.

Relatedly, there is an IsString property. This property is implemented like IsOfTypeString. If we create IsInt with this implementation, should it be permissible that something that has IsInt = true also have IsString = true? On the one hand, it can be used like a string. On the other hand, one would think these properties would be mutually exclusive. I can see a good argument for both sides.

Reply to this email directly or view it on GitHub:
#5 (comment)

from docopt.net.

Yeah, clearly IsOfTypeInt and IsOfTypeString should be mutually exclusive. My question was regarding the behavior of the new public properties IsInt and IsString. Should they behave like "CanBeConvertedIntoInt" and "CanBeConverteredIntoString", in which case a integer would be true for both? Or should they behave mutually exclusively where an integer value is not considered a string?

from docopt.net.

Thanks for the PR @kyle-fritz-zocdoc!

I think the first interpretation (CanBeConvertedIntoInt) makes sense as a general scenario and it would be consistent with properties like StringExtensions.IsInt. I do not see a scenario where a client needs to know if the value is stored as an int.

I will push a release with your changes soon.

from docopt.net.

Fix released as part of 0.6.1.5.

from docopt.net.