Skip to content

Restoration of Extension Methods #735

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

Closed
jonsuda opened this issue Jan 14, 2020 · 6 comments · Fixed by #742
Closed

Restoration of Extension Methods #735

jonsuda opened this issue Jan 14, 2020 · 6 comments · Fixed by #742

Comments

@jonsuda
Copy link

jonsuda commented Jan 14, 2020

My team has an existing project that uses a legacy version of UnitsNet (currently v3.102.0). We would like to upgrade to the latest version, but our code base relies heavily on the extension methods that were removed as part of the effort to cut down the size of the package (#372).

We understand the desire to keep the package small, which is why we’re not suggesting bringing the extension methods back into the main UnitsNet package. What we propose is creating another package, UnitsNet.Extensions (or something like that) specifically for these optional “convenience” pieces of functionality. (Bringing the extension methods back would be the first step; additional stuff might be added on a need-to-do basis in the future.)

As we need this functionality and will have to expend the effort to bring it back either way, we’d be more than happy to give back to the community by making our contribution open source (as opposed to simply doing it as our own project in our own private repository). We think it makes sense, however, for it to exist together with the rest of UnitsNet. In other words, we would like you to own it (even though we’re definitely open to making further contributions to it in the future).

Would you, in principle, be interested in such a contribution?

Here’s a summary of what we’re proposing:

  • We add another class library project, UnitsNet.Extensions (or similar), to the solution
  • We restore the code generator for the extension methods (convert it from PowerShell to C#)
  • We modify the build process to build and deploy an additional Nuget package, UnitsNet.Extensions; this package will have a dependency on the core UnitsNet package
  • Anyone interested in this auxiliary, “convenience” functionality can use this package, but it doesn’t affect the size of the core package
  • (We’ve already done much of this internally.)

Thank you!

@angularsen
Copy link
Owner

angularsen commented Jan 15, 2020 via email

@luli0401
Copy link
Contributor

Based on the discussion above, I've created a PR: 'NumberTo' Extensions Restoration #742.

@jonsuda
Copy link
Author

jonsuda commented Jan 28, 2020

@angularsen , do you think you'll be able to review our PR (#742 ) any time soon? It's currently blocking our intended UnitsNet upgrade. We could of course use our code internally, but we'd prefer to use the actual (UnitsNet.Extensions) Nuget package. We believe it should be simple :-) Thanks!

@angularsen
Copy link
Owner

@jonsuda Yes, I got around to it just now. Some comments in the PR.

@luli0401
Copy link
Contributor

luli0401 commented Feb 5, 2020

@angularsen Could you take a look the PR again when you have time? I've updated it based on our discussion. We are currently waiting for this extension to finish our tasks.
Thank you.

@angularsen
Copy link
Owner

@luli0401 yes, I just posted an update in the PR, let's continue the discussion there, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants