How do I set an option as an integer when using source generation?

[giggio]

I have tried several ways, I can't seem to find it.

[atifaziz]

The docopt format has no means of specifying the type of a positional or option argument therefore docopt.net doesn't support anything but string-based arguments at the fundamental level. This helps to keep the library simple, make it do one thing and try do it as well as possible. The moment you get into type conversion, you open a can of worms of expectations and the complexity explodes. The status of docopt.net is MVP for general utility. That doesn't mean such support cannot land in the future, but more on that later.

Once the parsing is done into properties of the arguments class generated by the source generator, it is up to the application to do the conversion to other types. This can be done through computed properties on another partial definition of the arguments type or layering a view on top through a wrapper class that provides more type-safety for an application's own internal use.

docopt.net does have some basic notion of an argument value kind:

docopt.net/src/DocoptNet/ArgValue.cs

Line 15 in cc1258e

/* ... */ enum ArgValueKind { None, Boolean, Integer, String, StringList }

But it's not what you might have in mind. There's a detailed design document about the source generator design that's work-in-progress in PR #119. It explains currently implemented features and some thoughts about future extensions. There's a section on Types that explains how the source generator decides (today) the fundamental type of an argument per the docopt format:

Types

The source generator selects an appropriate type for an argument property based on the following rules and the type of the argument (command, positional or option):

• Command:

  • A command property will have the type bool.

  • If the command can appear more than once, for example it is specified as command... in the docopt source, then the command property will have the type int and its value will reflect the actual repetition count.

• Positional Argument:

  • A command property will have the type string.

  • If the positional argument can appear more than once, for example it is specified as <argument>... in the docopt source, then the positional argument property will have the type StringList and its value will reflect the actual parsed values.

• Option:

  • A property for an option without any value (e.g. --option) will have the type bool.

  • A property for an option with a value (e.g. --option=value) will have the type string.

  • If an option without any value can appear more than once, for example it is specified as --option... in the docopt source, then the option property will have the type int and its value will reflect the actual repetition count.

  • If an option with a value can appear more than once, for example it is specified as --option=<value>... in the docopt source, then the option property will have the type StringList and its value will reflect the actual parsed values.

So as you can see, an option will be typed as int if it's allowed to be specified multiple times, like --option..., and what it tells you is how many times the user flagged it. For example, some tools allow a --verbose or -v option to be specified multiple times such that -v will mean verbose, -vv means very verbose and -vvv might mean debug-level diagnostics detail. A corresponding OptV on the arguments class will be typed as int and will be 1 for -v, 2 for -vv, 3 for -vvv and so on.

In the same document, there is a proposal about how type conversions could eventually be supported by the source generator, but this is not currently implemented. I have been using docopt.net in quite a few projects (see CSharpMinifier, for example) and so far, I haven't found a burning need for the source generator to support this; it's not itch I personally have that needs scratching. If someone wants to work on that, I'd be happy to entertain the idea.

[giggio]

Perfect, thanks for the answer.
Whqt could be interesting to solve that would be extension points. Virtual methods one could override to provide the extra validation.

[atifaziz]

I'd like to prevent inheritance and virtual dispatch because I don't think it'll necessary. The type conversion idea so far gets away with static methods entirely. It may be that certain validation may need access to other state/properties, but that is probably best done once the parsing is over; in other words, separate syntactic and semantic validation.