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