Add support for TypeConverter

[natemcmaster]

Followup to #59

We should

1. Add a TypeConverterParserAdapter. Implements IValueParser and takes an instance of TypeConverter.
2. Update ValueParserProvider to fallback to TypeConverterAttribute when present and return a TypeConverterParserAdapter.

As a bonus, we could either

• Update OptionAttributeConvention/ArgumentConvention to honor TypeConverterAttribute
• or, update those conventions to make it possible to override how the IValueParser is provided.

[natemcmaster]

Putting into the backlog for now as I don't plan to implement it myself. If someone stumbles upon this and wants to implement it, let me know. I'd accept a PR to add this.

[nohwnd]

@natemcmaster @rubenprins I looked into this, and read #59 and #51, I'd like to confirm what to do before I start implementing it.

From what I gathered from here :

The main reason is to have the possibility to override how a string is parsed to the target type by putting annotations on option properties. That way we could have:

[Option]
[TypeConverter(typeof(ChmodConverter))]
public int Permissions { get; set; } 

[Option]
public int Count { get; set;}

That would parse each property differently even though the have the same target type:

prg.exe --Permissions "-rwxr-----" --Count 21
Permissions = 740
Count = 21

(Sorry if I misinterpreted the original example, I am not 100% sure what octal chmod is, and this was the only case where it made sense to me:) )

The problem here is parsing the same type two ways does not fit with the api of ParserProvider. Parser provider chooses the parser based on the type of the data, not based on the property. For example this snippet from OptionAttributeConventionBase:

case CommandOptionType.SingleValue:
var parser = context.Application.ValueParsers.GetParser(prop.PropertyType);

I assume we cannot change how the ParserProvider works, so should I add a layer over it? It would select the TypeConverter from attribute if present, and fallback to TypeConverter when ParserProvider returns null.

[natemcmaster]

@nohwnd you are correct. There are two pieces of work here: allowing property-specific parser settings, and honoring TypeConverterAttribute as the way to set property-specific parsers. I think both should be possible without breaking existing API.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please comment if you believe this should remain open, otherwise it will be closed in 7 days.

[natemcmaster]

Partially addressed in #345. Need to add tests that validate this works as expected.