Skip to main content

Re: Proposal

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: Proposal
  • Date: Sun, 2 Nov 2014 12:19:39 +0100

That destroys type safety, because you can do
Time.add(Length) then if Quantity looked  like:

interface Quantity {
  public Quantity add(Quantity)
  ...
}

See OSGi Measurement, it allows non compile-time safe operations.
At runtime (just looked at the sources of its Unit and Measurement classes)
it won't do quantity checks but Unit.add(Unit) will prevent any addition of
a unit that is not "kg".
It sticks to SI and was very restricted, To  SI (it got 27 or so units,
covering all
http://en.wikipedia.org/wiki/International_System_of_Units#Base_units plus
most
http://en.wikipedia.org/wiki/International_System_of_Units#Derived_units)

Hence, add or subtract even to the same quantity if you defined a new unit
like "foot" would lead to a Runtime Exception.
Divide or Multiply works only between the most common SI types. There's
some strange type ID which, if 0 is considered a "special" unit, for all of
which divide and multiply fails in any case with a runtime exception.

Do we wanna end up there after what Unit-API 0.6 already accomplished?[?]


On Sun, Nov 2, 2014 at 11:50 AM, Otávio Gonçalves de Santana <
>
 wrote:

> Jean.
> Will don't remove Quantity interface, just the Generics in Quantity.
>
>
> interface Quantity {
> ...
> methods here
> }
>
> interface Time  extends Quantity {
> }
>
> On Sun, Nov 2, 2014 at 8:47 AM, Jean-Marie Dautelle 
> < >
> wrote:
>
>>
>> Actually, they are useful as a general contract for sub-interfaces to
>> make sure there is always consistency between a quantity unit and the
>> quantity itself. They also simplify the sub-interface definition (no need
>> to override add, subtract, times(Number).
>>
>> public interface Quantity<Q extends Quantity> {
>>       Unit<Q> unit();
>>       ...
>>       Quantity<Q> add(Quantity<Q>);
>>      ...
>> }
>>
>>
>> On Sun, Nov 2, 2014 at 11:27 AM, Otávio Gonçalves de Santana <
>>
>>  wrote:
>>
>>> I think it is cool, so we need to work with the specific interface, so
>>> the generics in Quantity, don't make more sense, so we could remove it 
>>> too.
>>>
>>> On Sun, Nov 2, 2014 at 8:15 AM, Jean-Marie Dautelle 
>>> < >
>>> wrote:
>>>
>>>> Or better:
>>>>
>>>> // Unit-API
>>>> interface QuantityFactory<N extends Number> {
>>>>      Length lengthOf(N, Unit<Length>);
>>>>      Mass massOf(N, Unit<Length>);
>>>>      ...
>>>> }
>>>> // Unit RI
>>>> abstract class Quantities {
>>>>      public static QuantityFactory<Double> DOUBLE = ...;
>>>>      public static QuantityFactory<BigDecimal> BIG_DECIMAL = ...;
>>>> }
>>>>
>>>>
>>>> On Sun, Nov 2, 2014 at 11:11 AM, Jean-Marie Dautelle <
>>>>  >
>>>>  wrote:
>>>>
>>>>> Erratum:
>>>>>
>>>>> / Unit-API
>>>>> interface QuantityFactory {
>>>>>      Length lengthOf(Number, Unit<Length>);
>>>>>      Mass massOf(Number, Unit<Length>);
>>>>>      ...
>>>>> }
>>>>>
>>>>>
>>>>> On Sun, Nov 2, 2014 at 10:50 AM, Jean-Marie Dautelle <
>>>>>  >
>>>>>  wrote:
>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> I understand your points, but I have the feeling that we are making
>>>>>> things more difficult than they need to be.
>>>>>>
>>>>>> We should not forget that the main subject is the unit-api not the
>>>>>> "quantity-api".
>>>>>>
>>>>>> Let's put ourselves in the shoes of the user and see what he might
>>>>>> want to do:
>>>>>>
>>>>>> public void wait(Time delay) { ... }
>>>>>> Mass m = parcel.getWeight();
>>>>>>
>>>>>> I would assume that until that point everyone agree... [?]
>>>>>>
>>>>>> Let's go deeper, we might want to do also:
>>>>>>
>>>>>> Length x = ...
>>>>>> Time t = ...
>>>>>> Velocity v = x.divide(t);
>>>>>>
>>>>>> If we can do that then I believe that even more people will be happy
>>>>>> (especially if it does not involve reflection) [?]
>>>>>>
>>>>>> ... And YES, it is possible!
>>>>>>
>>>>>> The first thing we see is that some of the quantities interfaces will
>>>>>> have extra methods.
>>>>>>
>>>>>> interface Length extends Quantity<Length> {
>>>>>>      Area multiply(Quantity<Length>); // Overloading.
>>>>>> }
>>>>>> interface Area extends Quantity<Area> {
>>>>>>      Volume multiply(Quantity<Length>); // Overloading.
>>>>>> }
>>>>>> Length x = ...
>>>>>> Volume v = x.multiply(x).multiply(x);
>>>>>>
>>>>>> There is no combination explosion since the number of predefined
>>>>>> quantities is bounded. Furthermore, all these are convenient (optional)
>>>>>> methods, the asType(Class<Q>) method can be used for complex cases.
>>>>>>
>>>>>> The question now is how do we create these Quantity instances?
>>>>>>
>>>>>> For this problem, the abstract factory pattern (GoF) is a perfect
>>>>>> fit. All quantities coming from the same factory will work well 
>>>>>> together
>>>>>> and this approach allows for many many optimizations under the hood !
>>>>>>
>>>>>> // Unit-API
>>>>>> interface QuantityFactory {
>>>>>>      Length lengthOf(double, Unit<Length>);
>>>>>>      Mass massOf(double, Unit<Length>);
>>>>>>      ...
>>>>>> }
>>>>>>
>>>>>> // Unit RI
>>>>>> abstract class Quantities {
>>>>>>      public static QuantityFactory DOUBLE = ...;
>>>>>>      public static QuantityFactory BIG_DECIMAL = ...;
>>>>>> }
>>>>>>
>>>>>> Length x = DOUBLE.lengthOf(2.4, METER);
>>>>>> Length two_x = x.add(x);
>>>>>> Area x_square = x.multiply(x);
>>>>>>
>>>>>> (Note: I would have preferred plus, minus, time, divide but I can
>>>>>> live with that [?])
>>>>>>
>>>>>> There is no need for a Measurement class (and MeasurementConverter).
>>>>>>
>>>>>> The quantity base class will be very close to what we have now except
>>>>>> it does not implement any interface.
>>>>>>
>>>>>> public interface Quantity<Q extends Quantity> {
>>>>>>       Unit<Q> unit();
>>>>>>       Number value();
>>>>>>       double doubleValue(Unit<Q>); // To avoid boxing/deboxing.
>>>>>>       Quantity<Q> add(Quantity<Q>);
>>>>>>      ...
>>>>>> }
>>>>>>
>>>>>> Of course if we can converge on this solution I would be really
>>>>>> really happy (JScience has many types of numbers such as Rational, 
>>>>>> Complex
>>>>>> for which this approach is a perfect fit) !!!
>>>>>>
>>>>>> Best regards,
>>>>>> Jean-Marie.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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)
>>>>
>>>
>>>
>>>
>>> --
>>> Otávio Gonçalves de Santana
>>>
>>> blog:     http://otaviosantana.blogspot.com.br/
>>> twitter: http://twitter.com/otaviojava
>>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>> 55 (11) 98255-3513
>>>
>>>
>>
>>
>> --
>> 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)
>>
>
>
>
> --
> Otávio Gonçalves de Santana
>
> blog:     http://otaviosantana.blogspot.com.br/
> twitter: http://twitter.com/otaviojava
> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
> 55 (11) 98255-3513
>
>

Attachment: 35C.gif
Description: GIF image

Attachment: 324.gif
Description: GIF image

Attachment: 330.gif
Description: GIF image

Attachment: 322.gif
Description: GIF image



Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Jean-Marie Dautelle 11/02/2014

Re: Proposal

Otávio Gonçalves de Santana 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

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
 
 
Close
loading
Please Confirm
Close