Use Advanced Search to search the entire archive.
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