Use Advanced Search to search the entire archive.
Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory
- From: Jean-Marie Dautelle <
>
- To:
- Subject: Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory
- Date: Fri, 31 Oct 2014 12:26:53 +0100
Dear All,
In order to be able to answer the question, I took this opportunity to
check the overall consistency of the unit-api.
Overall I am happy with it :) providing we correct a few important things.
Package spi:
- I would recommand to rename this package "service" (or "factory" if we
replace "Service" with "Factory" in all the classes' names).
- DimensionService is unnecessary/confusing. The dimensions instances
should be created through the Unit.getDimension method.
- QuantityService (or QuantityFactory) should be here (and not in the
package function)
Package quantity:
- Perfect :)
Package function:
- I understand that we want to put here functional methods, but there are
actually only two functional interfaces closely related to the unit-api :
Unit and Measurement conversion methods
Therefore, I would keep MeasurementConverter and UnitConverter but all
the others classes should be removed (ValueSupplier is another name for
Java 8 Supplier).
Package format:
- Classes UnitStyle and FormatBehavior are not used in the API and should
be removed or moved to the RI (if being used by the RI).
Package measure:
- There is a hierarchical inversion! Measurement should extends extends
Quantity and not the inverse (a measurement is a quantity "measured"; hence
with a value stated in a unit)
interface Measurement<Q> extends Quantity<Q> {
Number getValue()
Unit<Q> getUnit()
toUnit(Unit<Q>) // toUnit should be here and not in the Quantity
interface (a quantity intrinsically has no unit)
}
Now for the vote, to be consistent with the comments above.
In the RI we should have: class Quantities implements QuantityService;
hence the Quantities methods should return Quantity instances !
Cheers,
Jean-Marie.
On Thu, Oct 30, 2014 at 3:25 PM, Werner Keil
<
>
wrote:
>
Hi,
>
>
As Antoine just did some of those for CDI 2 on the Mailing list, let me
>
also try the same here. The last doodle triggered so much discussion on the
>
Mailing list, that the question probably could have been asked here in the
>
first place, too[?]
>
>
Should *Quantities *(
>
https://github.com/unitsofmeasurement/unit-ri/blob/master/src/main/java/tec/units/ri/quantity/Quantities.java)
>
return
>
1) a *Quantity *instance like it does now in both RI and SE port
>
or
>
2) a *QuantityFactory*?
>
similar to what JSR 354 does with MonetaryAmounts:
>
>
https://github.com/JavaMoney/jsr354-api/blob/master/src/main/java/javax/money/MonetaryAmounts.java
>
)
>
>
See https://java.net/jira/browse/UNITSOFMEASUREMENT-65
>
The outcome decides, whether we treat QuantityFactory as a core/mandatory
>
part of the API (keeping it under "function" I think it's better than a
>
slightly cluttered impression javax.money makes with 30 top level elements
>
[?]) or should move it to the optional SPI (which is optional especially
>
because the entire service part is optional in MEEP, too, hence providing
>
services on a device that has no use for it would be a waste)
>
>
Iit is not directly related to
>
https://java.net/jira/browse/UNITSOFMEASUREMENT-67 but both aim at
>
static "convenience factory" methods.
>
>
Making this simple, please try to reply like
>
+1 for 1)
>
or
>
+1 for 2)
>
>
not with a too lengthy discussion around it yet. It worked well for JSR
>
365, hope we can also get similar results here[?]
>
>
Thanks,
>
>
Werner
>
>
>
>
>
>
>
--
It is not the strongest of the species that survives, nor the most
intelligent. It is the one that is most adaptable to change. - Darwin's
Origin of Species (digest)
Attachment:
329.gif
Description: GIF image
Attachment:
347.gif
Description: GIF image