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:30:55 +0100
Another comments. Since most the user would want Measurement and not (too
abstract) quantities. It would make sence to provide MeasurementService
(and Measurements class) instead of QuantityService (and Quantities
classes). You might also want to shorten the name "Measurement" to
"Measure".
Cheers,
JM
On Fri, Oct 31, 2014 at 12:26 PM, Jean-Marie Dautelle
<
>
wrote:
>
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)
>
--
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