Identification of Units about uom HOT 9 OPEN

My suggestion is that instead of passing around the representation of the units in the application, I suggest that we only pass around the known unit names. When you want to do something with the unit, the library internally merges the unit structure into a map, and performs the same code as before. Serializing and deserializing becomes straightforward, a short string of unit name.

One solution that does not break compatibility could be to add an optional name to the unit while keeping the structural representation of the unit as it is today. That would probably clean up some of the code related to serialization. However this solution introduces more complexity as the unit now has another field and in some cases that field will not be set (when a new unit is the result of a calculation).

from uom.

Offline comment from @geon:

pass around the known unit names

Would it not be better to compare references to known objects?

from uom.

Offline comment from @AdamLuotonen:

That is what we are already doing, but if you check the unit tests we are supposed to support comparison of different references too. It would of course be most effective to just compare references, but that is not how the current thinking seems to be..

from uom.

Offline comment from @AdamLuotonen:

If one should identity the unit in another way than a reference it has to have some identifier (for example a unit name) or you will have to keep track of where the information about it came from. Then you can separate PoundLbPerPoundLb from KilogramPerKilogram. I think my vote is for the appraoch with identifier since we just use one set of known units everywhere anyway. And when you have a unique identifier in the unit you can put the derivation of the units in a registry in the library.

from uom.

My thinking is that it would be OK for an application to have a set of known units which it will have to keep within (which is what this proposal with identifier requires). In that case it should be up to each application to register the set of unit it wants to support. We could provide some units in the library, but the application could also add it's own to get a complete set. Perferable it would be possible to publish extra units as separate packages that are easily integrated with the uom core package.

from uom.

Here is a screenshot from an actual application to illustrate the problem:

from uom.

@jonaskello @AdamLuotonen so can we please implement the suggested solution? I could give it a try but I don't feel like I have the full understanding of how it works today and how to implement it. We really need it to be resolved in a month or so

from uom.

I believe this is fixed now. Can we close this issue?

from uom.

While the problem of identification is "solved", I'm still unsure if the solution is a good one. Having a name for each unit makes two equal units unequal just because they have different names. This is useful for some cases such as picking from a list where you need to identify each unit even if they are equal. But makes other cases impossible, such as deriving a new unit and finding out if it was the same as an existing unit.

from uom.