Design: builder API for parsing args into .NET types

[natemcmaster]

Problem
Users who prefer the builder API can't take advantage of the automatic type parsing available in the attribute api for int, List<T>, etc. Part of the difficulty is that CommandLineApplication, CommandArgument, and CommandOption only provide string-based properties.

Proposal
Add CommandOption<T> and CommandArgument<T>.

There is acts as an implicit requirement that values can be parsed to typeof(T).

For custom types, users can provide a custom converter to parse string into typeof(T). CLU will provide parsers for most commonly used types like int, double, bool, etc.

Usage

public static int Main(string[] args)
{
    var app = new CommandLineApplication();

    CommandArgument<int> arg = app.Argument<int>("arg", "argument");
    CommandOption<int> option = app.Option<int>("--arg", CommandOptionType.SingleValue)
        .Accepts().Range(0, 100);

    CommandOption<IPAddress> option2 = app.Option<IPAddress>("--addres", CommandOptionType.SingleValue)
        .UseConverter(val => IPAddress.Parse(val));

    app.OnExecute(() =>
    {
        int[] values = option.Values;
    });

    return app.Execute(args);
}

[natemcmaster]

I began playing with a prototype of this. Unfortunately, this will require some breaking API changes in order to make a common base-class that works between CommandArgument and CommandArgument<T>

[peterwurzinger]

@natemcmaster Won't CommandArgument just extend CommandArgument<string>? In the most common scenario arguments and options are strings imho, since this is obviously their type when passed to the application.

[natemcmaster]

It's a breaking change for other types that use CommandArgument. For example,

CommandLineUtils/src/CommandLineUtils/CommandLineApplication.cs

Line 147 in 2d8f039

public List<CommandArgument> Arguments { get; private set; }

[natemcmaster]

Maybe this would be better. It wouldn't require breaking changes.

class CommandArgument<T> : CommandArgument
{
     public T ParsedValue { get; }
     public IList<T> ParsedValues { get; }
}

Usage:

CommandArgument<int> arg = app.Argument<int>("arg", "argument");
app.OnExecute(() =>
{
   int[] values = arg.ParsedValues;
});

[peterwurzinger]

Ah, I didn't think of compositing types - my bad.

Your proposal looks quite good to me tbh, since one is then able to distinguish between a "normal" Argument, where you don't care about parsing into a .NET-Type, and "special" Arguments which have this abillity by explicitly accessing an additional property.

I just tried to come up with a solution to make it accessible through a common <whatevertype> Values { get; } - Property, but didn't do too well without bringing the big reflection-hammer.