Use Advanced Search to search the entire archive.
[jsr363-experts] Re: Quantity.doubleValue(...) ?
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: Quantity.doubleValue(...) ?
- Date: Mon, 15 Dec 2014 14:03:51 +0100
Answers inline
On Mon, Dec 15, 2014 at 1:29 PM, Martin Desruisseaux <
>
wrote:
>
Le 15/12/14 21:03, Werner Keil a écrit :
>
>
Base Unit is a concrete class, but if you think the general concept of
>
base and derived units would better suit the API concepts and terms, please
>
feel free to refactor.
>
>
I'm not talking about classes, but concepts. Before to be a class (if
>
implementor wish), base unit is first a concept defined by BIPM.
>
>
SystemOfUnits could (and probably should) have the following method:
>
>
Set<Unit<?>> getBaseUnits();
>
>
Note that the type in the returned set is Unit<?>, not BaseUnit<?>. The
>
concept of base units exists no matter how we represent it. Whether a
>
particular implementation decides to define a BaseUnit class for holding
>
that concept or not is an implementation details.
>
>
>
As there are so many possible systems (custom implementations like "Health"
or "Fitness" or country-specific ones, what should they all return there?
If it's only relevant to the SI implementing class, then I'd rather give it
to SI, possibly as a static method or extending the underlying class
(currently AbstractSystemOfUnits)
>
Those we declared only in the RI for now like Range or Measurement
>
should belong there, otherwise it creates the impression these are in the
>
API.
>
>
I agree that Range is not relevant to JSR-363 API. However I think that
>
the Measurement concept should be discussed in the "definition of terms"
>
part. Note again that I'm talking about the concept, not class. In the same
>
way that we can discuss about precision, accuracy, *etc.* without having
>
Precision or Accuracy classes.
>
>
Feel free to move it now, or later. Unlike Range (it and especially
QuantityRange another term OGC Sensor Web knows under the same name;-)
which we may prefer to leave any 3rd party implementation free to use
something else (Guava or whatever) it is not impossible to pull the
Measurement interface into the API if found appropriate.
Last time it was discussed, it seems most who participated felt it should
be in the RI. With a benefit that the SE implementation can offer at least
one or the other method like getInstant() beside the RI/ME compliant ones
like getQuantity() or getTimestamp(). It could also do so if it went into
the API.
The references especially to Fowler and others could be under general terms
and concepts, as long as it becomes clear why at the moment it is an RI
type.
>
Btw. what triggers the Unit-API JAR creation in the GeoAPI Maven repo?
>
Is that done manually?
>
>
This is automatic. The GitHib is verified every hour. If a new commit is
>
found, a new JAR creation is automatically trigged.
>
>
>
Here http://maven.geotoolkit.org/javax/measure/unit-api/
>
is only 0.7-SNAPSHOT, but the master already moved to 0.8-SNAPSHOT
>
allowing later bugs to be addressed e.g. the one around QuantityFactory.
>
What causes the latest Snapshot to be delivered there, too?
>
>
Should be automatic... If it is not, I will investigate what is happening.
>
It is not there at the moment.
>
>
>
And what about the 0.7 milestone release?
>
>
I'm on a slow network right now. I will try to deploy later tonight, when
>
I will be on a better network.
>
>
Martin
>
Thanks,
Werner