-
Notifications
You must be signed in to change notification settings - Fork 387
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
Use UnitConverter to do conversion functions and allow basic extensibility #1023
Conversation
|
||
var inBaseUnits = ToUnit(BaseUnit); | ||
|
||
if(!unitConverter.TryGetConversionFunction<Angle>(inBaseUnits.Unit, unit, out var conversionFunction)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it.
As a very minor performance improvement, can we call the innermost method overload? I think it has to go through 2 additional TryGetConversionFunction
methods to get to the most specific one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides the minor detail of failing tests, I think this looks good?
So in order to extend this, we can simply call Acceleration.DefaultConversionFunctions.SetXXX()
on startup?
Will there be a racing condition with the initialization of the global static UnitConverter.Default
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to formalize this more as we should really use QuantityInfo for the parameters.
What did you mean by this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it.
As a very minor performance improvement, can we call the innermost method overload? I think it has to go through 2 additional
TryGetConversionFunction
methods to get to the most specific one.
Done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides the minor detail of failing tests, I think this looks good?
So in order to extend this, we can simply call
Acceleration.DefaultConversionFunctions.SetXXX()
on startup?Will there be a racing condition with the initialization of the global static
UnitConverter.Default
?
You certainly could. I do worry a bit though about that causing unintended consequences, especially since GetValueAs
uses the DefaultConversionFunctions
. This would affect:
- operator +
- operator -
- operator <=
- operator >=
- operator <
- operator >
- CompareTo
- Equals
- As
That said, if you write a custom conversion function, arguably it should end up being used for * for example.
Codecov Report
@@ Coverage Diff @@
## master #1023 +/- ##
========================================
- Coverage 82.7% 80.4% -2.2%
========================================
Files 309 309
Lines 47598 46126 -1472
========================================
- Hits 39317 37081 -2236
- Misses 8281 9045 +764
Continue to review full report at Codecov.
|
Hmmm let me add some tests. Kinda shocked we don't have any tests for to base conversion in ToUnit! |
[Fact] | ||
public void ToUnit() | ||
[Theory] | ||
[MemberData(nameof(UnitTypes))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I parameterized a few tests to make them nicer
I think this is ready. I wonder why the new CodeCov report isn't coming through? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly nitpicks, which means the PR is good.
UnitsNet.Tests/GeneratedCode/TestsBase/AccelerationTestsBase.g.cs
Outdated
Show resolved
Hide resolved
I have no idea how the codecov is triggered. It almost seems random. |
It seems codecov failed to process the last uploaded coverage reports. Can't see any error codes or any details on what though. https://codecov.io/github/angularsen/UnitsNet/commit/b20c987ade7301039ed68e63b16137101e966ac3 |
Hey guys, I've just updated the release note- indicating that this is a breaking change for implementors of the IQuantity interface. |
And by the way- I haven't looked into this closely but - couldn't this be made into an extension method? We could still have the GetValueAs function call it by default, while people extending the main interface can choose to completely ignore it for their 'custom quantities'. |
Oops. Got a bit carried away there 😄 In retrospect, I think I should just remove the UnitConverter overloads. How the conversion / extensibility is implemented is just an implementation detail. Interfaces should be as small as possible to provide the required functionality and no more. Would you guys prefer removing them now (also a breaking change, although arguably for fewer consumers between minor versions), or making them obsolete for v5 removal? |
I think the impact of doing it now would be smaller (probably just me and you). |
I would tend to agree. I made #1047 to remove this overload. I will think about your other proposal in another PR, just wanted to get that break out (if @angularsen agrees this is the best action). |
I agree to remove for now to avoid breaking change in v4. I was thinking if we could maybe make use of default interface methods, but this seems limited to netstandard2.1 / netcore3 and I believe we should still support nestandard2.0. |
I had thought of that also, but I wouldn't be able to provide a default implementation anyways, since DefaultConverter lives on the individual quantity implementations, not interface definition. |
Co-authored-by: Andreas Gullberg Larsen <[email protected]> Fixes #1069 Per @lipchev's comments in #1023, I decided to add the local conversion method back (as private ```TryToUnit```). This will allow better performance for auto-generated conversions before falling back to the extensibility points.
Here's a very-rough initial idea for supporting #865.
Rather than generating functions that are not extensible, we can reuse our existing UnitConverter class and be able to use it for conversions. Users could add/remove custom functions at-will.
Need to formalize this more as we should really use QuantityInfo for the parameters.