-
Notifications
You must be signed in to change notification settings - Fork 393
Deprecate QuantityType to better support custom quantities #864
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
Conversation
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 think you made an excellent observation that we can reuse QuantityInfo
instead of QuantityType
for enumerating quantities, looking up one statically via Length.Info
or dynamically via Quantity.Infos
.
As in my comments, I propose we revert to keep old functionality and keep it backwards compatible, but mark it obsolete. Unit tests should test both old and new, until removed.
Then update #180 with what to remove and cleanup when we bump the major version.
There is a bunch of other stuff waiting there already.
What I didn't immediately see, is how do we achieve more extensibility than before?
Wiki describes how to extend with custom units, for converting or parsing, but it doesn't describe how to add custom quantities. One specific thing I believe is missing is how to add HowMuch
to Quantity.Infos
, which is currently an array. I can't immediately think of other scenarios where extensibility is lacking, but I'm sure there is something.
I'm totally fine with attacking that point later, just wanted to bring it up to hear if you had any thoughts of it.
Right, I forgot UnitsNet supports graceful removal of features. Obsoleting first makes total sense. Agreed that only when actual removal is done, tests should be removed. Would you please update #180, when the time is there?
We don't. We just remove a blocker on extensibility by changing the fact that the library relies on QuantityType. The PR effectively moves QuantityType to a role where it is not required to use any more, which is needed for extended quantities. Extended quantities can't provide a correct QuantityType value, and as such using api's where QuantityType is used will fail. That is what this PR fixes. I have opened #865 to discuss extensibility features in a tracking issue. I will update the PR to support obsoletion and initial addition of the QuantityInfo apis. |
Done. Could you re-review? Thanks! |
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.
Good progress, some findings below.
UnitsNet.Tests/GeneratedCode/TestsBase/AccelerationTestsBase.g.cs
Outdated
Show resolved
Hide resolved
Seems like tests fail on https://ci.appveyor.com/project/angularsen/unitsnet/builds/36677657
|
I have fixed some warnings and fought a little fight with Visual Studio, resulting in #pragma littering. That seems to be fixed now (I still wonder why previous week the build succeeded and now a reboot and restart reports all these warnings as errors. The ways of VS move in mysterious ways). I can't reproduce the error. Tracing it back points to if (Quantity.QuantityTypeByName.TryGetValue(name, out var quantityType))
QuantityType = quantityType;
else
QuantityType = QuantityType.Undefined; in the ctor of |
Pass QuantityType as argument with default value, instead of looking up in Quantity.
I pushed some fixes on a cyclic static ctor call, and fixed some test cases. |
Codecov Report
@@ Coverage Diff @@
## master #864 +/- ##
==========================================
- Coverage 83.09% 82.73% -0.37%
==========================================
Files 287 287
Lines 42987 43308 +321
==========================================
+ Hits 35720 35829 +109
- Misses 7267 7479 +212
Continue to review full report at Codecov.
|
AppVeyor is happy, I'll try to re-review this soon. |
How come the cyclic ctor call did not explode on my machine? I ran all tests. |
Try running One thing is that the order of tests. If any test in the same app domain (test project) called My best guess is that you were "lucky" to not get that particular test execution order. |
Gotcha, thanks. Is there anything you want me to do to move forward on this PR? |
No, I just need to read through the whole PR again. Maybe tomorrow. |
Replace MSBuildTreatWarningsAsErrors with TreatWarningsAsErrors Demote nullability errors to warnings in CodeGen until fixed.
@generateui I think this is ready to merge! Just waiting for AppVeyor to do its thing. It has been awfully slow lately. |
I was able to sort out the pragma stuff, see #872 . |
Quantity.g.cs had 30% lower test coverage, but we can sort that out later. I'd rather merge this beast now :D If I read it right, the method is not covered by tests: |
Nuget is on the way out, thank you for the contribution! |
This is awesome! Thanks for your close support. |
See #858. Turns out, QuantityInfo is already sufficient to represent a type of quantity. Hence, the solution is simple: remove QuantityType.
Tests pass, but I have not done a thorough check to actually merge the PR. Let's discuss first if this solution is desirable. To me, it solves the problem - QuantityType is gone, extensibility on QuantityType is now irrelevant.
Furthermore, users of all quantities can now use
Quantity.ByName
to enumerate all quantities.Please let me know if this is the direction this library want to go into. If so, I'll publish follow up changes to ready up for a merge.