Skip to main content

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



Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

(continued)

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/30/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/30/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Otávio Gonçalves de Santana 10/30/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Otávio Gonçalves de Santana 10/30/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Martin Desruisseaux 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Martin Desruisseaux 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Otávio Gonçalves de Santana 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Martin Desruisseaux 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Jean-Marie Dautelle 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Jean-Marie Dautelle 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Martin Desruisseaux 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Jean-Marie Dautelle 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Martin Desruisseaux 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Martin Desruisseaux 10/31/2014

Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory

Werner Keil 10/31/2014
 
 
Close
loading
Please Confirm
Close