Comments (9)
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.
Related Issues (20)
- Unit registry HOT 3
- Naming of unit name concepts HOT 2
- Clarify features HOT 2
- BTUPerHourPerSquareFeet
- How to extend this package from an external package HOT 11
- Release 2.0.0 HOT 2
- Conditional types for UnitTimes and UnitDivide
- Interesting repo HOT 3
- Don't publish sourcemap references HOT 1
- StandardLiterPerSecond is not calculated correctly HOT 2
- Request for new units
- ACFM and ACFH labels should be capitalized
- All amounts are effectively the same type. HOT 1
- Function Format.getUnitsForQuantity should not assume native units HOT 6
- Remove T extends Quantity and built-in Quantity union type. HOT 2
- Serialize needs to be optimized HOT 4
- Remove UnitFormat HOT 1
- Remove this function. Completely pointless.
- AlternateUnit, BaseUnit and ProductUnit don't use their type parameter. HOT 1
- Quantity Emission is not registered in QuantityInfo.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from uom.