Custom value conversion about clifx HOT 4 CLOSED

Initial design:

Extend CommandOptionAttribute/CommandParameterAttribute with an additional property Type? ConverterType { get; set; }. The converter has to implement some IArgumentConverter.

Since an argument can be scalar and non-scalar, in order to support both, IArgumentConverter would need to either have two methods (for a list of arguments and for one argument) or have one just for a list and let the user deal with it (nasty). It also needs a property IsScalar which is important when binding parameters from multiple arguments because it needs to be known pretty early.

This overall sounds pretty meh because it exposes quite a few points of failure where the user may forget something or do something incorrectly.

from clifx.

Current workaround without implementing anything:

Assume we have type MyType and a function MyType Convert(string). We can simply define our option/parameter as a string or IEnumerable<string> and then do the conversion inside ExecuteAsync manually. Not too pretty but still reasonable.

from clifx.

Hey, @Tyrrrz ! I would like to have a look at this issue. I maybe have a solution which works with both MyCustomType and IEnumerable<MyCustomType> and other generic collections, but I am not sure that I clearly catched what did you mean at It also needs a property IsScalar which is important when binding parameters from multiple arguments because it needs to be known pretty early. As I see, non-scalar types use same scalar type converters for each argument in the list, aren`t they?

from clifx.

Hi @AlexandrShustov.

As I see, non-scalar types use same scalar type converters for each argument in the list, aren`t they?

They do. I think when I wrote this I was thinking of cases where the user may want to convert the entire list, not just item by item. You can ignore this for now and see maybe it's not necessary after all.

from clifx.