Skip to main content

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

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory
  • Date: Thu, 30 Oct 2014 17:57:13 +0100

With the current methods in Quantities, the QuantityFactory makes no real
sense, as it is neither used nor exposed.
except for this Approach in the SE port, which IMHO we should leave to real
ServiceLoaders instead:
https://github.com/unitsofmeasurement/unit-impl-se/blob/master/src/main/java/tec/uom/se/quantity/QuantityFactoryProvider.java

Werner´

On Thu, Oct 30, 2014 at 5:54 PM, Werner Keil 
< >
 wrote:

> Aside from a facade class like Quantities being in the RI or SE port (or
> other implementations, we likely cannot force every platform to use one
> mechanism, that's exactly what Moneta does and at least one creator of an
> Eclipse based accounting and ERP app already argued, it would be
> incompliant with his Eclipse/OSGi solution[?]) rather than the API
> (javax.measure) it should be seen not too different from JSR 354 and
> MonetaryAmounts.
> That indeed Looks at the java.util.ServiceLoader and via SPI classes gets
> a MonetaryAmountFactory.
>
> As of now Quantities returns a pretty hard-wired Quantity implementation
> by asking for the numeric class, as you saw, the fallback is a generic
> BaseQuantity where (similar to ICU4J, it doesn't even Support primitive
> numbers at all) any Number class, also custom types like gnu.math.RealNum
> (extending Number in a very deep hierarchy, even a type named Quantity
> exists, but let's not go there, it has no compile time safety at all and
> allows to multiply by Object[?]) could be used.
>
> Please ask Otavio about the Long.class.cast(value), I suspect he considers
> it cleaner or safer than an explicit cast from discussions in other threads.
>
> Werner
>
> On Thu, Oct 30, 2014 at 5:35 PM, Martin Desruisseaux <
>  >
>  wrote:
>
>>  What would be the purpose to have Quanties to return QuantityFactory,
>> since QuantityFactory should probably be obtained by whatever Service
>> Provider mechanism the platform use (e.g. OSGi, or
>> java.util.ServiceLoader on JavaSE)?
>>
>> As a side note, I have a quick look at the code. Why code like that:
>>
>> if (Long.class.isInstance(value)) {
>>     return new LongQuantity<>(Long.class.cast(value), unit);
>> }
>>
>>  instead of:
>>
>> if (value instanceof Long) {
>>     return new LongQuantity<>((Long) value, unit);
>> }
>>
>>  The Class.isInstance and Class.cast methods are useful when the class
>> is unknown at compile time. But in the above code they are not necessary.
>>
>>     Martin
>>
>>
>>
>> Le 30/10/14 23:25, Werner Keil a écrit :
>>
>>  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
>>
>>
>>
>>
>>
>>
>>
>>
>

Attachment: 329.gif
Description: GIF image

Attachment: 347.gif
Description: GIF image



[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

Martin Desruisseaux 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

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
 
 
Close
loading
Please Confirm
Close