Use Advanced Search to search the entire archive.
Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory
- From: Otávio Gonçalves de Santana <
>
- To:
- Subject: Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory
- Date: Thu, 30 Oct 2014 18:17:46 +0000
+1 for 1)
On Thu, Oct 30, 2014 at 6:12 PM, Otávio Gonçalves de Santana <
>
wrote:
>
This method are equivalent, just cleaner and OO aspect.
>
>
>
http://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#isInstance-java.lang.Object-
>
>
http://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#cast-java.lang.Object-
>
>
On Thu, Oct 30, 2014 at 4: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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
>
Otávio Gonçalves de Santana
>
>
blog: http://otaviosantana.blogspot.com.br/
>
twitter: http://twitter.com/otaviojava
>
site: *http://about.me/otaviojava <http://about.me/otaviojava>*
>
55 (11) 98255-3513
>
>
--
Otávio Gonçalves de Santana
blog:
http://otaviosantana.blogspot.com.br/
twitter:
http://twitter.com/otaviojava
site: *
http://about.me/otaviojava <
http://about.me/otaviojava>*
55 (11) 98255-3513

