Skip to main content

Re: Proposal

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: Proposal
  • Date: Sun, 2 Nov 2014 11:50:43 +0100

I don't think so, especially not on the API level, otherwise it becomes
limited to only the few interfaces or classes we use.

If we went that far, nearly every use case was destroyed or impossible.
Look at OpenXC, it supports merely 10 quantities, for a car.
We have 50 quantities, most of them exactly like Unit-API 0.6 which many
current or potential users will consider a blueprint. If we destroy what it
accomplished, especially compile-time safety for addition, subtraction and
conversion we failed the purpose and people may well stick to OSGi
Measurement, ICU4J or OpenXC on Android[?]

 Werner

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

Attachment: 35C.gif
Description: GIF image

Attachment: 324.gif
Description: GIF image

Attachment: 330.gif
Description: GIF image

Attachment: 326.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

Re: Proposal

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