Skip to main content

Re: Proposal

  • From: Jean-Marie Dautelle < >
  • To:
  • Subject: Re: Proposal
  • Date: Sun, 2 Nov 2014 15:01:21 +0100

For ME the following implementation should work (no reflection and no OSGi
services):

In Unit-API

interface QuantityFactory<N extends Number, Q extends Quantity<Q>> {
     Class<N> getValueType();
     Class<Q> getQuantityType();
     Q of(N value, Unit<Q>);
}

In RI:

abstract class Quantities { // Double implementation.
     public static <Q extends Quantity<Q>> void
setFactory(QuantityFactory<Double, Q>, Class<Q>) { ... } // Allows for
custom registration.
     public static <Q extends Quantity<Q>> QuantityFactory<Double, Q>
getFactory(Class<Q>)
{ ... }
     public static QuantityFactory<Double, Mass.class> MASS =
getFactory(Mass.class);
     public static QuantityFactory<Double, Length.class> LENGTH =
getFactory(Length.class);
     ...
}

class QuantityImpl<Q extends Quantity<Q>> implements Quantity<Q> {
    ...
    <R extends Quantity<R>> R asType(Class<R> type) {
         unit.asType(type); // Raises exception if dimension mismatch.
         QuantityFactory<Double, R> factory = Quantities.getFactory(type);
         return factory.of(value, unit);
    }
}



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

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



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

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

Re: Proposal

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