Use Advanced Search to search the entire archive.
Re: On Quantity - Measurement relationship
- From: Jean-Marie Dautelle <
>
- To:
- Subject: Re: On Quantity - Measurement relationship
- Date: Sat, 1 Nov 2014 16:52:59 +0100
>
Mass mass = myObject.getMass();
If you want to do that (which is possible) you will need Mass (hence
Quantity) to provide some useful value/unit pair.
Otherwise, I don't know what you would do with Mass !!
This goes back to proposition #1
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);
>
>
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.
>
>
>
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
>
>
>
>
--
It is not the strongest of the species that survives, nor the most
intelligent. It is the one that is most adaptable to change. - Darwin's
Origin of Species (digest)
Attachment:
361.gif
Description: GIF image