Use Advanced Search to search the entire archive.
[jsr363-experts] Re: Remove javax.measure.format.Parser interface
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: Remove javax.measure.format.Parser interface
- Date: Tue, 16 Dec 2014 12:17:46 +0100
Though not in the API you'll find a similar very general purpose Range in
the RI/SE port.
Extended by QuantityRange which is parameterized by Quantity.
The thing is, I found important use cases for each of the two already;-)
Since we came to the conclusion we must have <?> wildcards for certain
operations, QuantityRange will simply fail for a BMI example like
https://github.com/unitsofmeasurement/uom-demos/blob/master/domain/health/src/main/java/tec/uom/demo/health/BMIRange.java
but works perfectly well for known quantities like Speed in
https://github.com/unitsofmeasurement/uom-demos/blob/master/console/ri/src/main/java/tec/uom/demo/types/SaffirSimpsonHurricaneWindScale.java
Until we are sure every parser worked with a distinct <Quantity> that's
exactly why Parser is so generic while UnitFormat is at least specialized
to Unit<?> (you must not know what you get from a plain text file, which is
why UCUM doesn't care at all about the "quantity" package;-) We'll explore
the needs of the community (see Opower who already used and extended the
UCUM features JScience 5 "Draft" provided) and also work closely with other
JSRs along the lines of JSON-P 1.1, JSON-B (where I joined the EG) or
others under the EE 8 umbrella. It is likely to parse also things like
Quantity, so Unit<?> baked in could be contraproductive.
HTH,
Werner
On Tue, Dec 16, 2014 at 10:51 AM, Martin Desruisseaux <
>
wrote:
>
>
Le 16/12/14 18:46, Leonardo Lima a écrit :
>
> I agree that IF we should have parsing in the API, it has to be optional.
>
I agree to keep parsing and formatting optional. But it is unclear for
>
me at this time why parsing service is separated from the (parsing &
>
formatting) service, and I'm a bit worried by the "in between" state of
>
the Parser interface: designed as if it wanted to be more generic than
>
Unit & Measurement, but not really more generic because of its exception
>
which is (indirectly) specific to Unit & Measurement.
>
>
> I still didn't see value in it from the device PoV, but maybe from a
>
> server-side it can have some value. I suggest we leave it as is for
>
> now and explore more the use case.
>
Okay. I will fill a JIRA task a little bit later.
>
>
Martin
>
>