v5 Roadmap

[angularsen]

TODO Summarize what will make the cut for v5
#1158 merges v5 to master, prerelease nugets are already out.

What remains before we can call it a release and postpone the rest for v6?

Temperature arithmetic

In #518 we discussed changing this. Long story short, it's ambiguous what addition and subtraction of Temperature should result in, because 0 Celsius != 0 Fahrenheit != 0 Kelvins. Some people expect the temperature difference (ex: 30 C - 20 C = 10 delta C), others expect a new temperature (ex: 30 C - 20 C = 303 K - 293 K = 10 K = -263 C). We currently don't know what ratio of people favor one way over the other, so to make an informed decision I think we need to poll our userbase somehow or find a way to implement this that will cause the least amount of confusion.

PRs #550 + #560 implemented this change, but we realized we were not able to agree on whether to make this change or not in time for v4.

[Mobz87]

An Idea:
A global-default unit.

An example:

We could set the global unit for pressure:
GlobalUnit.Pressure = Pressure.Psi

If I set a new pressure:
_pressure.Value = 10;
Then it is loaded in as 10 Psi

Using _pressure.Value
will return 10

Using _pressure.Unit
return 'Psi'

using _pressure.ToString();
return 10 Psi

My idea is not to change the unit for which it does it calculations behind the scene, just changing the unit it using on its in/outputs if nothing else is specified.

[tmilnthorp]

Doesn't seem like anything the client application couldn't do where you stash a static "global" or default unit and pass it into the constructor or From method.

I think you're also potentially talking about the idea in #547

[angularsen]

I think in general it is not a good idea to tamper with global static variables in a library. If you're using another library or project that also depend on UnitsNet, but expects different defaults, you can easily run into issues here. Also the default behavior shipped with UnitsNet could change in a major version bump, possibly causing similar issues if you have a lot of code just passing in values and assuming some unit will be used. It just sounds flaky with not much benefit in my eyes, but I can understand the convenience sounds appealing.

This kind of convenience is also very easy to build per-application, just create a factory type like this:

static class Quantitator2000
{
    public PressureUnit DefaultPressureUnit { get; set; } = PressureUnit.Psi;
    public Pressure Pressure(double value) => new Pressure(value, DefaultPressureUnit);
}

var p = Quantitator2000.Pressure(200); // 200 Psi

[SGStino]

Extensibility

I'd recommend moving the units to their own interfaces instead of Enums.
This would let us to add units at runtime, fiddle around with dependency injection, ..

ITemperature[] temperatureUnits = new []{
    new Temperature(0, 1, "Kelvin", "K"),
    new Temperature(274.15, 1, "Celcius", "°C"),     
    ...
}

This could of course for convenience be implemented in:

public class Temperature : ITemperature
{
    public static ITemperature Kelvin {get;} = new  Temperature(0, 1, "Kelvin", "K")
}

Could be used in DependencyInjection frameworks:
services.GetService<ITemperature>().FirstOrDefault(n => n.Name == "Kelvin")
to avoid using reflection directly.

The Quantity<> object could then use the IUnit interface to do the conversions through the SI values?

The base features could be extended with custom abbreviations/namings, that could be automatically picked up by the parsers etc..

The biggest issue I'm facing with Units.NET currently is interop with other systems. For most parts the abbreviations are correct, but sometimes they just don't translate well (LPH instead of L/h, ...).
EDIT: seems I just discovered how I might fix this issue, by reading https://github.com/angularsen/UnitsNet/wiki/Upgrading-from-3.x-to-4.x
must have overlooked that functionality when scanning those classes

A lot of that would be fixable by setting up some dependency injection and allowing library users to inject their custom unit definitions into the system at runtime.

[SGStino]

Compound Units (L/h, m/s)

Units should combine information form their base units. Allowing combinations to exist without explicitly adding them:

Velocity should be Length/Time, and as such, allow any length and time unit, not just the ones defined in the jsons, if a new length unit gets added, a new velocity unit should become available.

Prefixes (kilo, hecta, deca, ...)

Don't have Kilogram as a separate Unit from gram etc.
Instead link a prefix system to the unit type.

SI's kilo, mega, giga, ...
or binary kibi, mebi, gibi, ...

Both these would mean that using Enums is no longer an option though, but that might be a good thing considering #563 (comment)

[angularsen]

In quantities like Length, rename the property BaseUnit to DefaultUnit or IntermediateUnit to avoid confusion with the new BaseUnits per unit, since both are defined in JSON.
Also update the names in JSON and the PS1 code generator scripts.

#601 (comment)

[angularsen]

Change all string culture parameters to to IFormatProvider.

Example UnitConverter:

UnitsNet/UnitsNet/UnitConverter.cs

Line 214 in c4cab69

public static double ConvertByAbbreviation(QuantityValue fromValue, string quantityName, string fromUnitAbbrev, string toUnitAbbrev, string culture)

[AlexC84]

isn't this temperature arithmetic confusion a result of confusing the distinction between points in affine space vs translation vectors in affine space?

e.g.

• You can add translation vectors to a points/locations in affine space to get an new point
• You can subtract two points in affine space to get a translation vector
• You can add/subtract two translation vectors to get another translation vector

You can't add two points in affine space to get a new location or a vector - it doesn't make sense. i.e. London + Oslo = ? but London - Oslo = 1,160miles

A temperature measurement is a point on the temperature scale (1D affine space) in relation to the chosen origin. A temperature difference is a translation vector

Some people expect the temperature difference (ex: 30 C - 20 C = 10 delta C), others expect a new temperature (ex: 30 C - 20 C = 303 K - 293 K = 10 K = -263 C).

• Correct: 30 C - 20 C = 10 delta C (point - point = vector)
• Incorrect: 30 C - 20 C = 303 K - 293 K = 10 K = -263 C (point-point <> point)

[angularsen]

@AlexC84 You are not wrong, but as outlined in the top post and in the discussions of the issues it links to, I believe it comes down to what people of different technical backgrounds or when working in different contexts, what they expect is the correct behavior here.

The current behavior is what you consider correct, that subtraction results in TemperatureDelta. Others from science or engineering backgrounds have claimed that Temperature is the expected quantity. It would also then follow the same arithmetic behavior as all our other quantities.

The main argument against changing it is that in order to do a breaking change I need to be convinced that we are changing it for the better; that more people will like it than dislike it. I don't currently know if that statement holds.

So, unless someone bring convincing evidence that the majority will favor changing Temperature - Temperature from TemperatureDelta to Temperature, then I don't want to make the change.

[tmilnthorp]

I would expect 30C - 20C to equal 10 (unitless).

That's the way boost units works too actually

[angularsen]

Nice, a third option, this keeps getting better 😆

I have don't have any strong opinions on this myself, I think it's fine as it is. I don't see a clear "winner" of the three options, and I reckon some people will probably be confused no matter what method we go with. I do think that returning TemperatureDelta at least makes it more clear to the consuming code what is going on and I believe the main confusion was that people try to do ToString() on the result and see that 30C - 20C = 10 C. I believe we improved that part by adding the delta symbol so it now reads "10 ΔC" or something similar.