Skip to main content

Re: Proposal

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: Proposal
  • Date: Sun, 2 Nov 2014 15:22:18 +0100

I'd certainly use <T> for type, but as this was already in the pipeline, I
reopened https://java.net/jira/browse/UNITSOFMEASUREMENT-66

We need full proof that it works even in a minimalistic environment like
that Paul and I created for JUnit tests:
https://github.com/unitsofmeasurement/unit-api/tree/master/src/test/java/javax/measure/test/quantity

P.s.: whatever the other names, a QuantityFactory must not declare of(),
except for itself (but we can't do Lambdas in ME for now[?]) so the method
would still be create() whatever it returns.

 Werner


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

> 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

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

Re: Proposal

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