Return decimal for decimal-based quantities #1074
Conversation
pgrawehr
changed the title
pgrawehr
force-pushed
the
decimalConversion2
branch
from
2ac3232
to
206b7b8
Compare
|
Will get to this, just a bit short on time these days. |
|
@angularsen No worries, take your time. Good coders are always busy ;-) |
UnitsNet.Serialization.JsonNet.Tests/UnitsNetBaseJsonConverterTest.cs
Outdated
Show resolved
Hide resolved
|
I was not able to push a change, so here is the diff I tried to push regarding As() overloads: 0001-Simplify-As-overloads-by-reusing-and-casting-to-doub.patch.txt |
|
@angularsen There seems to be a weird problem with the use of |
|
On the phone, but we can't make breaking changes in v4. Either we must fix
it or move this change to v5 branch.
|
|
@angularsen The entire PR is intended to go to v5 only. |
|
Aha, my bad. I think we need to figure out why these tests are failing and fix them, because I don't want to remove the compatibility tests so we can make sure we aren't breaking anything. https://ci.appveyor.com/project/angularsen/unitsnet/builds/43692947/tests I don't have time to help look into it right now, but might be able to assist later this week. |
|
Hey guys, I've just had a look at this - and it appears that the only tests that are failing are from the |
|
@lipchev Yea, it's still strange that the test fails, as it only uses old implementations (or maybe not?) I forgot about this, but I'll have a look when I find time. |
|
It's incorrect in referencing the converter via the nuget, while the UnitsNet core is referenced using a project reference. Had the reference to the converter been via direct reference it would have caused a compile time issue at the moment that the old converter was removed, thus forcing us to also remove the converter tests (i.e. the whole project).. |
|
@angularsen You write above that you want the compatibility tests still to pass, but given v5 doesn't even have the |
|
Although it might be argued that the tests actually did their intended purpose- if that was to test the latest UnitsNet version against UnitsNet.Serialization.JsonNet v4.4.0 - it was correct in establishing that UnitsNet v5 is not compatible with it. :) |
|
I just removed the compatibility tests from release/v5 and merged it into here, I agree they no longer serve a purpose. |
Even though it seems nice, it could probably cause quite a bit of confusion.
|
@angularsen Hi! I've lost track of this one a bit, but how shall we go on? It would be good if we could finally come to a conclusion (and get V5 out!) There's also a build failure now that I think is unrelated to the PR. |
|
Sorry for late reply, I've been missing out on some email notifications on
this repo lately. I'll need to revisit this and refresh my brain on it,
will get back to you.
|
|
@angularsen It would be good this could be taken on hand some time soon. I'm actually waiting for a v5.0 release due to some other internal changes that make stuff easier (and of course the included fixes). |
|
Thank you for the reminder, I pushed some minor fixes and I think this is ready to merge now. Awesome job! By the way, v5 is already out as a alpha prerelease nuget. It does lag behind master on new units though, because each merge to update that branch incur the mother of all merge conflicts. 🙈 I still have a few breaking changes I'd like to get around to before stabilizing the v5 nuget, but other than that it should be good to use already. |
angularsen
changed the title
Fixes #180 Merging the v5 release branch. It is still in alpha, but it is functional, nugets are published and there are not many planned breaking changes left. By merging, all efforts moving forward are targeting v5 and this reduces friction: - No more merge conflicts trying to forward port all changes to v5, instead cherry pick new units and fixes to v4 until v5 is fully stable. - Contributors are having trouble building v4 locally due to `net40`, `net47` and Windows Runtime Component targets. ## 💥 Breaking changes Default number format should be CultureInfo.CurrentCulture, not CurrentUICulture (#795) Use CurrentCulture rather than CurrentUICulture (#986) Return `QuantityValue` in `IQuantity` properties instead of `double` (#1074) Return `decimal` in properties of `Power`, `BitRate` and `Information` quantities (#1074) Fix singular name VolumeFlow.MillionUsGallonsPerDay ## 🔥 Removed Remove targets: net40, net47, Windows Runtime Component. Remove `Undefined` enum value for all unit enum types Remove QuantityType enum Remove IQuantity.Units and .UnitNames Remove IQuantity.ToString() overloads Remove IEquatable<T> and equality operators/methods Remove GlobalConfiguration Remove obsolete and deprecated code. Remove Molarity ctor and operator overloads Remove MinValue, MaxValue per quantity due to ambiguity Remove string format specifiers: "v", "s" json: Remove UnitsNetJsonConverter ## ✨ New QuantityValue: Implement IEquality, IComparable, IFormattable QuantityValue: 16 bytes instead of 40 bytes (#1084) Add `[DataContract]` annotations (#972) ## ♻️ Improvements Upgrade CodeGen, tests and sample apps to net6.0. ## 📝 JSON unit definition schema changes Rename `BaseType` to `ValueType`, for values "double" and "decimal". Rename `XmlDoc` to `XmlDocSummary`. ## TODO Add back `IEquatable<T>`, but implement as strict equality with tuple of quantity name + unit + value. #1017 (comment) ## Postponed for later #1067
|
I merged v5 into master now by the way. |
Great. I'll start testing it asap. We're preparing a major release in dotnet/iot that will bring a bunch of breaking changes, and therefore is a good time to also upgrade UnitsNet. |
Fixes #1058
Return the correct value type for quantities that use
decimalinternally;Power, Information, BitRate.decimalordoublebased on internal value type.IQuantity.ValuereturnsQuantityValue, which supports both double and decimal.QuantityValue: Implement IEquality, IComparable, IComparable.