Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show default values of non-required options in help #17

Closed
Tyrrrz opened this issue Aug 19, 2019 · 8 comments · Fixed by #54
Closed

Show default values of non-required options in help #17

Tyrrrz opened this issue Aug 19, 2019 · 8 comments · Fixed by #54
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@Tyrrrz
Copy link
Owner

Tyrrrz commented Aug 19, 2019

Suggested approach:

  • Resolve target command
  • Instantiate the command but don't fill the values
  • Get the values of the properties on the freshly-instantiated command, filter out those that are default and show them in help text
@Tyrrrz Tyrrrz added the enhancement New feature or request label Aug 19, 2019
@Tyrrrz Tyrrrz added the good first issue Good for newcomers label Aug 29, 2019
@domn1995
Copy link
Contributor

To clarify the spec for this feature, how do we want to handle types without "nice" ToString() outputs? Just print out the result of ToString() and if it's ugly it's ugly? For types that implement IEnumerable we can just string.Join() the values of course, though.

Another way to say this is that any of the types supported by the built in value conversions get nicely formatted default values and the rest are not guaranteed. @Tyrrrz, what do you think?

@Tyrrrz
Copy link
Owner Author

Tyrrrz commented May 12, 2020

Totally forgot about that :/

We could check if ToString() is overriden but even if ToString() is overridden on a type, there's no guarantee that it will return the value in the same form it expects to parse. I think for now we should just handle the basic types and IEnumerable<T> of those via string.Join.

@domn1995
Copy link
Contributor

domn1995 commented May 12, 2020

Yup, that sounds good. How do we want to handle types that do NOT override ToString()?

Ignore them? Print the type name? Print some placeholder value indicating a warning?

Another option is adding a Default property to CommandOptionAttribute where the user can supply a string to print as the default value. If they supply it, we just print that, otherwise we defer to our implementation.

With that last option, we could add an analyzer that checks whether the type doesn't override ToString() and show a warning suggesting they override or set the Default property of the CommandOptionAttribute.

@Tyrrrz
Copy link
Owner Author

Tyrrrz commented May 12, 2020

Let's only handle these types:

var primitiveConverter = PrimitiveConverters.GetValueOrDefault(targetType);
if (primitiveConverter != null)
return primitiveConverter(value);
// Enum
if (targetType.IsEnum)
return Enum.Parse(targetType, value, true);
// Nullable
var nullableUnderlyingType = targetType.GetNullableUnderlyingType();
if (nullableUnderlyingType != null)
return !string.IsNullOrWhiteSpace(value)
? ConvertScalar(value, nullableUnderlyingType)
: null;

Another option is adding a Default property to CommandOptionAttribute where the user can supply a string to print as the default value. If they supply it, we just print that, otherwise we defer to our implementation.

That would break single source of truth, I don't like that. If the user decides to change the property type or the actual default value, they will have to remember to also update the default string value in attribute.

@domn1995
Copy link
Contributor

domn1995 commented May 12, 2020

That would break single source of truth, I don't like that. If the user decides to change the property type or the actual default value, they will have to remember to also update the default string value in attribute.

Yeah, I don't like that either, but it would be mostly remedied by an analyzer catching it.

Still not sure what behavior we want for the unsupported types... I think I'll print something like Default: unknown value for now and eventually have an analyzer that warns on it.

@Tyrrrz
Copy link
Owner Author

Tyrrrz commented May 12, 2020

I vote we just don't do anything for unsupported types, i.e. leave the current behavior.

@domn1995
Copy link
Contributor

I vote we just don't do anything for unsupported types, i.e. leave the current behavior.

I think I'm ok with that if we get an analyzer warning eventually 😎

@Tyrrrz
Copy link
Owner Author

Tyrrrz commented May 13, 2020

@domn1995 after we merge this in, I'm gonna refactor code a bit so don't pick anything else until I'm done :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants