Skip to main content

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



Re: On Quantity - Measurement relationship

(continued)

Re: On Quantity - Measurement relationship

Martin Desruisseaux 11/01/2014

Re: On Quantity - Measurement relationship

Werner Keil 11/01/2014

Re: On Quantity - Measurement relationship

Martin Desruisseaux 11/01/2014

Re: On Quantity - Measurement relationship

Werner Keil 11/01/2014

Re: On Quantity - Measurement relationship

Martin Desruisseaux 11/01/2014

Re: On Quantity - Measurement relationship

Werner Keil 11/01/2014

Re: On Quantity - Measurement relationship

Martin Desruisseaux 11/01/2014

Re: On Quantity - Measurement relationship

Werner Keil 11/01/2014

Re: On Quantity - Measurement relationship

Martin Desruisseaux 11/01/2014

Re: On Quantity - Measurement relationship

Werner Keil 11/01/2014

Re: On Quantity - Measurement relationship

Jean-Marie Dautelle 11/01/2014

Re: On Quantity - Measurement relationship

Martin Desruisseaux 11/01/2014

Re: On Quantity - Measurement relationship

Werner Keil 11/01/2014

Re: On Quantity - Measurement relationship

Werner Keil 11/01/2014

Re: On Quantity - Measurement relationship

Martin Desruisseaux 11/01/2014

Re: On Quantity - Measurement relationship

Werner Keil 11/01/2014

Re: On Quantity - Measurement relationship

Werner Keil 11/01/2014

Re: On Quantity - Measurement relationship

Martin Desruisseaux 11/01/2014

Re: On Quantity - Measurement relationship

Werner Keil 11/01/2014

Re: On Quantity - Measurement relationship

Martin Desruisseaux 11/01/2014

Re: On Quantity - Measurement relationship

Werner Keil 11/01/2014
 
 
Close
loading
Please Confirm
Close