Use Advanced Search to search the entire archive.
Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory
- From: Martin Desruisseaux <
>
- To:
- Subject: Re: [VOTE] Should a Quantities facade return Quantity or QuantityFactory
- Date: Fri, 31 Oct 2014 20:50:01 +0900
- Organization: Geomatys
Thanks Jean-Marie for looking on the API.
Le 31/10/14 20:26, Jean-Marie Dautelle a écrit :
>
Package spi:
>
- I would recommand to rename this package "service" (or "factory"
>
if we replace "Service" with "Factory" in all the classes' names).
I'm somewhat neutral on this one. However JavaSE consistently use "spi"
everywhere (java.util.spi, java.text.spi, etc.). How would we justify a
departure?
>
- QuantityService (or QuantityFactory) should be here (and not in
>
the package function)
I agree.
>
Package function:
>
- I understand that we want to put here functional methods, but
>
there are actually only two functional interfaces closely related to
>
the unit-api : Unit and Measurement conversion methods
>
Therefore, I would keep MeasurementConverter and UnitConverter but
>
all the others classes should be removed (ValueSupplier is another
>
name for Java 8 Supplier).
Ton of +1 !! Me too I think that ValueSupplier should be considered out
of JSR-363 scope.
>
Package measure:
>
- There is a hierarchical inversion! Measurement should extends
>
extends Quantity and not the inverse (a measurement is a quantity
>
"measured"; hence with a value stated in a unit)
Or alternatively, we may try to rename Measurement in something else.
Indeed it may be preferable to avoid any type named "Measurement" in
JSR-363, because many groups have a much more complex idea of what a
measurement is (e.g. must have an estimation about accuracy or quality,
etc.). In our case, the "Measurement" idea was "something (not
necessarily a scalar) with a unit of measure". For example a vector is
not a scalar quantity, but still have a unit of measurement. So as I see
it, the open question is: how to rename "Measurement" for catching the
idea of "something with a unit of measure"?
>
interface Measurement<Q> extends Quantity<Q> {
>
Number getValue()
>
Unit<Q> getUnit()
>
toUnit(Unit<Q>) // toUnit should be here and not in the Quantity
>
interface (a quantity intrinsically has no unit)
>
}
Actually the above hierarchy may fit the vocabulary, but is different
than the current Quantity intend. It may be a vocabulary problem: what
we call "Quantity" in JSR-363 is actually a "Scalar" for physicists.
Renaming "Quantity" as "Scalar" would have be more accurate for those
familiar with physics science and would make sense with the current
hierarchy (we could even keep the current Measurement interface). But
"Scalar" has been discarded because too many peoples are not familiar
with this term.
Do we start a separated thread named "Agree on quantity, measurement and
scalar definitions" and see if we revisit some interface name accordingly?
>
Now for the vote, to be consistent with the comments above.
>
In the RI we should have: class Quantities implements QuantityService;
>
hence the Quantities methods should return Quantity instances !
But an implementation does not need to expose publicly its
QuantityService implementation. If Quantities does nothing else than
implementing QuantityService, then it does not need to be public. I
though that the only point to make Quantities a public class would be
convenience, in the form of static methods. This also match the usual
JavaSE practice, where classes in plural form are usually a set of
static methods (e.g. java.util.Collections).
Martin