Skip to main content

Re: Proposal

  • From: Jean-Marie Dautelle < >
  • To:
  • Subject: Re: Proposal
  • Date: Sun, 2 Nov 2014 14:09:13 +0100

I think we are getting close but in the Quantities interface we should have
a stronger contract:

public interface Quantity<Q extends Quantity> {
     ...
     <R extends Quantity<R>> R asType(Class<R> cls);
}

QuantityImpl<Q extends Quantity<Q>> implements Quantity<Q> {
     double value;
     Unit<Q> unit;

     <R extends Quantity<R>> R asType(Class<R> type) {
          unit.asType(type); // Raises exception if dimension mismatch.
          R r = cls.newInstance();
          // Since we are using an abstract factory pattern, the following
works for all quantities produced by the same factory.
          ((QuantityImpl)r).value = value;
          ((QuantityImpl)r).unit = unit;
          return r;
     }
}

This allow us to go back to "strong typing" whenever we need it (e.g. to
avoid parameter clashes).

Mass m0 = m1.multiply(m2).divide(m3).asType(Mass.class);



On Sun, Nov 2, 2014 at 1:19 PM, Werner Keil 
< >
 wrote:

> Please see an experimental probe for one of the types that already has
> full unit test coverage thanks to work by Paul and myself in 0.6
>
> https://github.com/unitsofmeasurement/unit-api/blob/master/src/main/java/javax/measure/quantity/Length.java
>
> With test classes
>
> https://github.com/unitsofmeasurement/unit-api/blob/master/src/test/java/javax/measure/test/quantity/DistanceQuantity.java
> and
>
> https://github.com/unitsofmeasurement/unit-api/blob/master/src/test/java/javax/measure/test/quantity/AreaQuantity.java
>
> Martin is right, it would add dependencies between at least the basic SI
> types so (which is currently legally impossible anyway, [?]) one could not
> just pick "Length" from the "quantity" package and implement it without
> Area, etc.
>
> Werner
>
> On Sun, Nov 2, 2014 at 1:11 PM, Jean-Marie Dautelle 
> < >
> wrote:
>
>> > I also assume, you don't want to eliminate the to(Quantity) method from
>> Quantity, do you?
>>
>> Not necessarily. A quantity may be stated in any compatible unit.
>>
>> public void wait(Time delay) {
>>     long microseconds = delay.to(MICRO(SECOND)).longValue();
>>     Thread.wait(microseconds);
>> }
>>
>> > WDYT?
>>
>> Fully agree, the API should have only interfaces!
>>
>>
>> On Sun, Nov 2, 2014 at 12:50 PM, Werner Keil 
>> < >
>> wrote:
>>
>>> I also assume, you don't want to eliminate the to(Quantity) method from
>>> Quantity, do you?
>>>
>>> Fowler proposes exactly that signature, though he also leaves it open to
>>> create a separate Converter element, see JSR 354 simply because you need 
>>> to
>>> know a lot  more for currency conversion like time, date, type (cash, 
>>> card,
>>> bond, ...) of monetary amount, etc.
>>> So far we had a fairly simple conversion here, nevertheless typesafe
>>> thanks to generics.
>>>
>>> If only Quantity existed, then like in other cases MeasurementConverter
>>> (defining the to()) and ValueSupplier would only serve one interface, 
>>> hence
>>> could logically be merged into Quantity.
>>>
>>> If a common understanding is (unlike OpenXC where non-numeric quantities
>>> are indeed also treated typesafe via a "Unit", but it got no operations on
>>> the other hand) a multitude or non-numeric quantity would not even have a
>>> unit, then the current Measurement becomes redundant, as the only purpose
>>> would be to make these multitudes type-safe, too.
>>>
>>> In the interest of an ultra-slim approach for smallest devices (that
>>> need just a single Unit and Quantity, either from our pre-defined SI stack
>>> or something completely different)
>>> could we move the now "orphaned" QuantityFactory and SystemOfUnits into
>>> SPI (as they have no external dependencies to them in mandatory 
>>> base-types)
>>> and push UnitConverter up into the root package instead?
>>>
>>> This makes us or users more flexible regarding optionality all optional
>>> packages depend only on the base elements, not even on each other[?]
>>> And only the root package "javax.measure" contains mandatory core
>>> elements.
>>>
>>> WDYT?
>>>
>>> On Sun, Nov 2, 2014 at 12:40 PM, Jean-Marie Dautelle 
>>> <
>>> > wrote:
>>>
>>>> > Do I'm understanding right?
>>>>
>>>> Yes 100 %
>>>>
>>>> On Sun, Nov 2, 2014 at 12:24 PM, Martin Desruisseaux <
>>>>  >
>>>>  wrote:
>>>>
>>>>>  Hello Jean-Marie
>>>>>
>>>>> To summarize, you are suggesting three things:
>>>>>
>>>>>
>>>>>    1. Remove the Measurement interface in order to avoid the
>>>>>    conceptual problem with hierarchy.
>>>>>    2. Define the Quantity interface as a quantitative measurement
>>>>>    (since it contains a value and a unit).
>>>>>    3. Overload the multiply and divide methods for type safety.
>>>>>
>>>>>
>>>>> Do I'm understanding right?
>>>>>
>>>>>     Martin
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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)
>>>>
>>>
>>>
>>
>>
>> --
>> 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)
>>
>
>


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

Attachment: 347.gif
Description: GIF image



Re: Proposal

(continued)

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

Martin Desruisseaux 11/02/2014

Re: Proposal

Martin Desruisseaux 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Martin Desruisseaux 11/02/2014

Re: Proposal

Werner Keil 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

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