Use Advanced Search to search the entire archive.
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:26:27 +0100
+1 for 2)
I'd prefer to keep this harmonized with JSR-354. The QuantityFactory
Interface itself is fairly small. Only if it was rendered useless because
not used by e.g. Quantities then it's better to make it optional. Otherwise
we had other places to tweak, e.g. SystemOfUnits (which is also a
specialized kind of "factory" if you want)
Along the lines of CDI the vote closes within *72h*. Please reply with your
Preference before Sun night.
Werner
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
>
>
>
>
>
>
>
Attachment:
329.gif
Description: GIF image
Attachment:
347.gif
Description: GIF image