Skip to main content

Re: On Quantity - Measurement relationship

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: On Quantity - Measurement relationship
  • Date: Sat, 1 Nov 2014 17:03:20 +0100

That's what happened in JSR-275 though it had a Number/Unit pair, but no
operations at the time.
 #1 would be a slightly improved version of that or Unit-API 0.6, but for
anything in the "multitude" quantities force to carry a useless getValue()
which you normally won't be able to define as not-a-Number any more (unless
you carry a Quantity<Q, V> kind of signature[?]

 Werner


On Sat, Nov 1, 2014 at 4:52 PM, Jean-Marie Dautelle 
< >
wrote:

> > 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: 35F.gif
Description: GIF image

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

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

Re: On Quantity - Measurement relationship

Martin Desruisseaux 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