Skip to content

Add support for guid options - #345

Merged
natemcmaster merged 1 commit into
natemcmaster:masterfrom
AlexeyEvlampiev:master
Feb 19, 2020
Merged

Add support for guid options#345
natemcmaster merged 1 commit into
natemcmaster:masterfrom
AlexeyEvlampiev:master

Conversation

@AlexeyEvlampiev

Copy link
Copy Markdown
Contributor

Fix to #333 "System.InvalidOperationException: on parsing GUID command line option"

@natemcmaster natemcmaster left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job! This looks good and is a job well done for a first PR ever. Thanks for the contribution!

A few things

  • As this code depends on an API (TypeDescriptor) which is unavailable in .NET Standard 1.6, I'm unable to backport this to the 2.6 release that I was planning to release soon (cref #338). This will be in the 3.0 release which I hope to get done sometime in spring. After this merges, I'll post a link to the custom nuget feed where I publish nightly builds so you can try pulling this into your own project.
  • Are you okay if I add your username to the release notes and CHANGELOG to thank you for your work?
  • I have a few questions about behavior, as posted below.

Thanks again,
Nate

return true;
}

var converter = TypeDescriptor.GetConverter(targetType);

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've never used this API before. Do you know what other kinds of types this supports? Also, does this incidentally implement support for TypeConverterAttribute? If so, this is a two-birds-one-stone PR and also resolves #62.

@AlexeyEvlampiev AlexeyEvlampiev Feb 17, 2020

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, the change made does address #62. The requested functionality is implemented in the form of an implicit fallback, when no custom value parser is registered for an argument type. In principle the change introduced support for a wide range of CLR types (e.g. TimeSpan, Version etc.). And yes, your right. The TypeConverterAttribute functionality is enabled with this change. So custom types annotated with TypeConverterAttribute will be parsed automatically.

var converter = TypeDescriptor.GetConverter(targetType);
if (converter.CanConvertFrom(typeof(string)))
{
if (_parsersByTargetType.Count >= _maxCacheCapacity)

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is there a limit to 100 type converters?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Limiting the cache capacity prevents the excessive memory consumption under stress loads or invocations triggered by a malfunctioning caller. I subjectively chosen 100 as the requirement to support more than 100 different argument types per command line application is unlikely. Still, the component is capable of handling these exotic cases with some performance penalty (approximately 3 times slower).

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spoken like a perf-minded engineer. :) I see where you are coming from, but I think this might be premature optimization. It appears that the implementation of TypeDescriptor is already caching its results and has some memory optimizations under the hood (like using WeakReference). (see https://github.com/dotnet/runtime/blob/master/src/libraries/System.ComponentModel.TypeConverter/src/System/ComponentModel/TypeDescriptor.cs) I think we can simplify this code by skipping the cache and count checks.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is fine by me. This component is private anyway.

@@ -0,0 +1,123 @@
namespace McMaster.Extensions.CommandLineUtils.Abstractions
{
using System;

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: the formatting of your code doesn't exactly match with the rest of the project, but I don't blame you -- Visual Studio (and .NET in general) don't provide me with good ways to help new contributors follow a consistent code format. After this is merged, I'll reformat to fit with the rest of the project. That will change a few things, such as moving usings to the top of the file, adding accessibility modifiers, removing regions, and adding braces to conditional code. Of course, you're welcome to make those changes yourself and push and update to this PR, but it's not a requirement :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can Roslyn based extensions help with enforcing the chosen code style?

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Know of any good ones? My criteria is that I need a tool that works on my macbook and can be easily used by all contributors without installing something heavy like ReSharper. I've toyed with integrating dotnet-format into the build.ps1 script, but it's not very good yet and always gives me false warnings on my macbook due to it's broken implementation of loading the MSBuild project system.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really. But it is something I am considering to look into, when the time comes.

@AlexeyEvlampiev

Copy link
Copy Markdown
Contributor Author

Good job! This looks good and is a job well done for a first PR ever. Thanks for the contribution!

A few things

  • As this code depends on an API (TypeDescriptor) which is unavailable in .NET Standard 1.6, I'm unable to backport this to the 2.6 release that I was planning to release soon (cref Remove .NET Standard 1.6 target framework #338). This will be in the 3.0 release which I hope to get done sometime in spring. After this merges, I'll post a link to the custom nuget feed where I publish nightly builds so you can try pulling this into your own project.
  • Are you okay if I add your username to the release notes and CHANGELOG to thank you for your work?
  • I have a few questions about behavior, as posted below.

Thanks again,
Nate

I am very happy to hear that and definitely positive to be mentioned in the release notes and CHANGELOG . Thanks!

@natemcmaster natemcmaster linked an issue Feb 18, 2020 that may be closed by this pull request
@natemcmaster

Copy link
Copy Markdown
Owner

Thanks for the contribution! I'll make sure to add you to the release notes 😄

@natemcmaster
natemcmaster merged commit dc17772 into natemcmaster:master Feb 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

System.InvalidOperationException: on parsing GUID command line option. Add support for TypeConverter

2 participants