Adding support for Tuple<T1, T2, ...> as option/value parsing target

[gsscoder]

I want to be able to parse this:

$ app --webserver localhost 8080

to:

class Options {
  [Option] public Tuple<string, int> WebServer { get; set; }
}

Opinions? cc/ @mizipzor @nemec @gimmemoore

[alexanderfast]

This seems to go against the standard. To have it accepted you would have to quote the
"localhost 8080" part since it contains a space. But it just looks weird. Although in this specific case, an uri, the solution is obvious since it has an accepted syntax localhost:8080. Off the bat, I cannot come up with a case where the above makes sense.

[gsscoder]

@mizipzor, I'm not agree, why one have to quote input?

In this case just think a tuple like a heterogeneous typed sequence. As long as T1, T2, Tx... types of Tuple<...> match input, the parser will collect values, convert them and create appropriate Tuple instance.

I think it's good also for forcing an order without effort. E.g. 8080 before localhost will generate a conversion error.

Probably will complicate the parsing kernel, but I thik it could be useful for some scenarios.

Obviously it's a feature that must be used correctly like in my sample.

E.g.: if I want capture exactly 10 int I'll use an [Option(Min=10, Max=10)] mapped to IEnumerable<int> not a Tuple<int, int, int...> (also if it works the same); but this is a design problem of the developer and doesn't concern us (I think).

[alexanderfast]

My only argument is that its simply not how the original getopt works, to have spaces you either quote them or escape them. As long as that is still required I have nothing against adding support for tuples. People know getopt and having the library behave like getopt is a feature (and a good one at that). If the library works "like getopt with a few tweaks", it is not as attractive.

[nemec]

The only benefit I can see here is the ability to specify multiple tuple options in a single argument string, otherwise there doesn't seem to be much benefit over using a Verb with ValueAttributes: $ app webserver localhost 8080

Additionally, this syntax maps a single OptionAttribute to multiple parsed values (T1...TN) which makes configuration of each inner option more difficult. For example, it would be nice if your sample webserver defaulted to 8080 if a port wasn't provided but I'm not sure how that could be specified.

Maybe one compromise could be to let the OptionAttribute be tagged on custom classes (like Verbs) but that contain only ValueAttributes (or create a new MultiValueOptionAttribute), which could allow you to re-use the parsing logic that already exists for Values.

Another option, slightly more verbose, could be to add the ability to define "option groups" that require all options in the group to be defined or none at all:

$ app --server localhost --port 8080  # allowed
$ app --server localhost              # fail, missing --port
$ app --port 8080                     # fail, missing --server

Personally, I agree with @mizipzor that keeping consistency with getopt is a very good thing (especially now that C# is becoming more cross-platform) and for this particular example adding a colon separator (localhost:8080) is the more accepted option.

[gsscoder]

@nemec, thanks for comments!

Personally I see a Tuple<T1, T2, ...> as compound data type. I don't see it as something against getopt()...

A true thing instead is that two Value attribute can mimic this behaviour in some way.

Any other comment?

[alexanderfast]

No more comments, I've said my part and still hold the same opinion.