Create Quantity from Unit as part of API about unit-api HOT 8 CLOSED

Quantity is just one kind of object used together with Unit. It is suitable for occasional use like metadata, but I would discourage its use for actual data. For example in tabular data (spreadsheet, database, etc.), the Unit is more efficiently associated to the column as a whole, and all numerical values in that column use the same unit of measurements. So the Unit instance is not associated to a particular Quantity, but rather to a whole column (or matrix, or data cube). This allow the use of much more efficient data structures (double[], Matrix). For example, it is much more efficient to get a UnitConverter once between two units and apply it for thousands of numerical values, than to let Quantity searches again and again for the unit conversion for each numerical value.

In short, Quantity is good for some occasional uses (in particular metadata), but I would discourage its use for large amount of data.

from unit-api.

Yes I agree, I do the same thing in most cases. Most of the time I do in fact work with double[] and Unit exactly as you describe.

But I'm not convinced that really addresses my question, after all Quantity exists for a reason and sometimes it is useful and appropriate. Why not make it as easy as possible to use?

So again, is there a good reason for QuantityFactory to exist instead of just Unit.createQuantity(Number)? I'd understand the philosophical argument that you want to keep the dependency between Unit and Quantity one-directional, from the latter to the former, but this is already not the case.

from unit-api.

They are separate entities, take plenty of other similar APIs e.g. ICU4J with MeasureUnit and Measure, the closest equivalent to Quantity (implementations like Indriya know a Measurement, but it is literally that and also holds a timestamp, so the measurement goes beyond the ICU4J Measure which only contains unit and number. JSR 363 needs to work all the way back to at least Java 7 or (if recompiled the right way) could even work under SE 6 or 5, too. First of all they don't even know a static factory method like Unit.createXYZ() or Unit.of(). Almost any JSR or simiar API has one or more central static factory singletons. Something like Caching, Monetary or ServiceProvider in our case.
JSON-P has a very similar combination:

JsonObject json = Json.createObjectBuilder()
     .add("name", "Falco")
     .add("age", BigDecimal.valueOf(3))
     .add("biteable", Boolean.FALSE).build();

see https://javaee.github.io/jsonp/

from unit-api.

Yes they're kinda separate. The interfaces do both interdepend (at least before erasure) and the designs are imo deeply related in both directions ... but sure, the implementations can be independent and instances of Unit can be used independently of any implementation of Quantity.

I understand the appeal of that, but my suggestion doesn't really change much, it only requires that the implementation of a system of units be parameterizable with (and thereafter any instances be tied to) some mechanism to instantiate Quantity.

I don't think much value is lost there, and imo the value gained is greater. We can nolonger work with Units without an implementation of Quantity somewhere on the classpath ... but in 99% of cases this will be true anyway.

Currently for people who do need to work with Quantity their code may well be littered with QuantityFactory references and the like, at least unless they make some concessions on design. If they're using only a single implementation of QuantityFactory (as almost everyone will) this feels a bit redundant and messy.

Well I think I can understand why the decision would be made this way philosophically, even my personal needs and opinions ask for something slightly different. I appreciate you taking the time to discuss it.

from unit-api.

Yes, although for Generic Typesafety, you'll never get to use the Unit without a Quantity, because Unit<Q extends Quantity<Q>> shows, you need the quantity interface, too. We decided to combine them. A few solutions like F# call this aspect Dimension, so they combine the Quantity and Dimension. Others like ICU4J call it "type", but that library is only run-time type-safe, and it doesn't even offer conversion between METRE and FOOT etc. out of the box. The aim of it lies only on the presentation in different languages.

from unit-api.

I'm interested in examples of code cluttered with calls to QuantityFactory. This would allow us to:

• If we think that the user should be using a more efficient data structure like double[], we could write a "best practices" chapter somewhere.
• If this is a use case where Quantity is well appropriate, explore if we can propose different ways to make user's task easier.

My reticence against a Unit.createQuantity(Number) method are:

• It would encourage non-informed users to create Quantity everywhere, even in situations where he should be using a double[] or something else. It would contribute to the impression that Java is slow.
• If Unit can create Quantity, why not Vector, Matrix, Tensor, etc.? Where to stop?
• What should be the primitive type? double? float? BigDecimal? If we keep Number for allowing any type, it would increase the "Java is slow" perception if those quantities are used a lot.
• How Unit should choose which QuantityFactory instance to use? We may have more than one on the classpath (e.g. if you have both Apache SIS and Unit RI on the classpath).

from unit-api.

We already have Quantities.getQuantity() for exactly that purpose. Internally it may also call the SPI, although at the moment it is more a central factory and the QuantityFactory implementation which we need for implementation-neutrality (not everyone outside the JCP may fully understand that) in the RIs also uses the Quantities class underneath the hood. Because Quantities is not part of the API/SPI right now, that is also fine. Quantities also does some selection, e.g. which datatype to use. Unit.getQuantity() would just be another convenience method. If it was static which Java 8/9 would allow, it still had to use the SPI, otherwise the method call could have a default in Java 8+ but it would again be implementation-specific.

from unit-api.

Based on input by @desruisseaux and others, let's close this for now. It can always be filed again or reopened if found appropriate.

from unit-api.