Use Advanced Search to search the entire archive.
Re: On Quantity - Measurement relationship
- From: Werner Keil <
>
- To: "
" <
>
- Subject: Re: On Quantity - Measurement relationship
- Date: Sat, 1 Nov 2014 16:31:49 +0100
On Sat, Nov 1, 2014 at 4:12 PM, Martin Desruisseaux <
>
wrote:
>
There is a fourth option:
>
>
4. Keep the current hierarchy by defining JSR-363's Quantity as a
>
*quantitative
>
measurement* (or a physical quantity). However names could be changed if
>
that help.
>
>
Option 2 has the following consequences:
>
Questionable use of "measurement" word
>
>
Measurement extends Quantity imply that a measurement is always a scalar,
>
which I question. To me, a vector is also a measurement, which implies that
>
Measurement can not extends Quantity. However the second name proposal (
>
Amount) seems to work.
>
Weaker constraint on parameterized type
>
>
If Quantity is the base interface instead than the subtype, then Unit<Q
>
extends Quantity<Q>> or any other object parameterized with Quantity
>
would accept types that do not make much sense. For example in addition to
>
Unit<Length> and Unit<Mass>, such hierarchy would also accept
>
Unit<Measurement>. If we want to prevent such thing, then the Quantity
>
interface (or whatever we name it) must be a subtype of Measurement (or
>
whatever we name it).
>
Mass, Length and other Quantity subtypes become less useful
>
>
Since Quantity would be an empty interface, Mass, Length and other
>
Quantity sub-types become nothing more than marker interfaces, which make
>
them less useful. With the current hierarchy, it is possible to write:
>
>
Mass mass = myObject.getMass();
>
>
I also argue that we can write the following type-safe expression
>
(Werner said that it doesn't work, but from my understanding he tried to
>
implement that by using reflection on the parameterized type, which is
>
indeed of limited use in current Java. I was thinking more about the
>
Unit<Q> implementation having a Class<Q> internal field containing the
>
necessary information):
>
>
Mass mass = (Mass) a.multiply(b);
>
>
These never worked, since we got a generic multiply operation on Quantity
and concrete classes like DoubleQuantity.
DoubleQuantity does not implement Mass, so returning Mass causes
ClassCastExceptions everwhere.
>
But with option 2, it is no longer possible. We would have no other
>
choice than writing:
>
>
Measurement<Mass> mass = myObject.getMass();
>
>
and the above type-safe cast is no longer possible - a
>
Measurement.asType(Class<Q>) method become the only alternative I can see.
>
>
>
Why, if Measurement was
Measurement<Q extends Quantity<Q>> extends Quantity<Q> this worked
perfectly fine.
See UOMo
http://git.eclipse.org/c/uomo/org.eclipse.uomo.git/tree/bundles/org.eclipse.uomo.units/src/main/java/org/eclipse/uomo/units/IMeasure.java
or (while that was a class)
JScience
http://www.jscience.org/api/org/jscience/physics/amount/Amount.html
Where the term Amount was also used.
No significant Unit-supporting API uses other names than Measure or
Measurement if they use the concept.
ICU4J has the "loophole" of calling all children of Measure *Amount, a bit
of an inconsistency one may say.
With slightly different at times, 2 of the newer "quantified" JSRs like 354
or 310 both contain base interfaces with a name like *Amount, too.
Werner
Martin
>
>
>
Le 01/11/14 22:53, Jean-Marie Dautelle a écrit :
>
>
Hi All,
>
>
Here are the different options, I think:
>
>
1. Quantity and Measurement are merged into a single Quantity
>
abstraction having a value (number) and a unit (and there is no Measurement
>
abstraction)
>
>
2. Measure(ment)/Amount extends a high level Quantity abstraction (which
>
allows for very abstract quantities, even enum, e.g. Mass m = HEAVY, no
>
value and no unit). Note: We see in that case that Quantity cannot
>
implement Comparable. HEAVY/LIGHT may depend on the context, the boundary
>
may not be well defined or be relative, e.g. we can compare HEAVY with
>
LIGHT but not HEAVY with another mass).
>
>
3. Quantity and Measure(ment) have distinct hierarchies. A Measure(ment)
>
is not a quantity but a numerical/scalar representation of it (the same way
>
that the image of an Elephant is not an Elephant).
>
>
All options are valid and the choice is yours [?] !
>
>
My personal favor goes for 2
>
>
Cheers,
>
JM
>
>
>
>
Attachment:
361.gif
Description: GIF image