Closed
Description
Although there are no immediate plans to do a vNext, this issue serves as a wishlist/reminder of what to consider changing in case we need to bump the major version in the future.
To clarify
These are some things we should figure out before finalizing version 4.
A common denominator for design choices is binary size.
The library was nearing the 1MB mark and the majority of that is the large number of methods and properties for all our 700+ units. In particular number extension methods add 8 methods per unit (!). With some clever hacks we brought this back to 600kB without any breaking changes, but we want to keep binary size in mind for any new changes we introduce.
TODO Clean up and organize this brain dump:
- Numeric type for value representation: Keep
double
? Switch todecimal
? Offer both? Separate nugets? What aboutfloat
? - Base types: To make it easier working with quantities generically, accessing value and unit, get units and their abbreviations, parsing and ToString() without know the quantity type in advance.
struct
vsclass
: Weigh all the pros and cons, performance (stack vs heap), inheritance vs interfaceclass
: Can support all number types (float, double, decimal) without increasing binary size N times (discussion)struct
: More suitable for performance and memory constrained applications (what is the impact in practice?), avoids pressure on garbage collector, quantities match the semantics of being a value type
List of breaking changes to make
Removing things
- 7a455f0: Remove default
Temperature
arithmetic, it is not correct (made this breaking change already, due to existing behavior not being correct).RemoveUnitClass
type, replaced byQuantityType
Remove nullableFrom
factory methods causing N additional methods for N units, see commentRemove==
!=
andEquals(object)
andEquals<T>(T)
since they don't take a max error argument and is prone to floating point rounding issues, instead users should useEquals()
methods that take a max error argumentRemove code marked as[Obsolete]
, such asVolume.Teaspoon
unit that was too ambiguousRemove static methods onUnitSystem
, should useUnitSystem.Default
insteadRemove unnecessary overloads on number types (8 overloads for each of the 700+ units) Proposal: Reducing size of library (WIP) #372
Changing behavior
- Throw exception on NaN values in unit class constructor methods (Support NaN #176)Throw if unit was not specified when constructing quantities Preserve value and unit #389 (comment)Stricter parsing (see "Length.TryParse" parses invalid values #343 and v5: Wishlist for breaking changes #180 (comment))
Renaming
- Correct SingularName for some Flow unit definitions (see Add more Flow units #360)
Fixing
- Search for any TODO comments in the code to address, remove comment and either fix or create issue
Activity
angularsen commentedon Nov 26, 2017
Ping @JKSnd @eriove @ferittuncer to subscribe to updates to this thread.
Question: Should we change this
to this
Delta is already covered by the quantity, so it feels redundant. Just noticed this when reviewing https://github.com/angularsen/UnitsNet/pull/324/files#diff-1067499ac8bb37a45676058d184d0547R55
eriove commentedon Nov 27, 2017
Yes, that sounds like a good change. We could add the new function and mark the old one as obsolete immediately. That would make the migration easier
gojanpaolo commentedon Jan 9, 2018
Please add this to wishlist: Correct SingularName for some Flow unit definitions.
see #360
bplubell commentedon Jan 11, 2018
I propose making parsing stricter:
Length.Parse("2.3 m")
Length.Parse("2.3 m and 200mm")
FeetInches
.Length.Parse("1ft 5.5in")
andLength.Parse("1\"5.5'")
Length.Parse("1ft and 4in")
This would be more in consistent with framework parsing methods (like
double.Parse
), which are not very lenient. The burden lies with the consumer to provide data that is not ambiguous.See #343 for additional context.
Related PRs from originally allowing multiple units:
#64
#81
#254
angularsen commentedon Jan 13, 2018
@bplubell How about we actually have a separate parsing method for the feet-inch special case? Something like
Length.ParseFeetInches(string)
? I think maybe it is reasonable to make it explicit that we are expecting such input, as opposed to having this special case as part ofLength.Parse()
.Or maybe this just complicates things from the consuming side of things.. I'm not sure.
gojanpaolo commentedon Jan 14, 2018
Remove inconsistent abbreviation for cubic feet
cf/hr
in Flow (See #361 (review))12 remaining items
angularsen commentedon Oct 15, 2018
Closing this since most of the discussions above are covered in v4 #487.
Creating new discussions for the remaining topics, such as changing from
struct
toclass
.v4.0.0 (#487)
v5 Release (#982)
[-]vNext: Wishlist for breaking changes[/-][+]v5: Wishlist for breaking changes[/+]