Skip to main content

Re: Proposal

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

Errata: Actually the previous implementation cannot work.
We need to use the proper quantity factory.

 <R extends Quantity<R>> R asType(Class<R> type) {
      unit.asType(type); // Raises exception if dimension mismatch.
      QuantityFactory<R> factory = ...; // Find it (e.g. OSGi service)
      return factory.of(value, unit);
}

This is where OSGi can be of tremendous help as users may register new
factories for their custom quantities.
For non-OSGi users, extension is more difficult (mechanisms should be
provided by the RI).


On Sun, Nov 2, 2014 at 2:09 PM, Jean-Marie Dautelle 
< >
wrote:

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



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

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

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Otávio Gonçalves de Santana 11/02/2014
 
 
Close
loading
Please Confirm
Close