Skip to main content

Re: Proposal

  • From: Otávio Gonçalves de Santana < >
  • To:
  • Subject: Re: Proposal
  • Date: Sun, 2 Nov 2014 22:31:23 -0200

The method asType should exist just when you do some operation like divide
or multiply or inverse.

Quantity<Length> metre = Quantities.getQuantity(BigDecimal.TEN, SI.METRE);
Quantity<Length> metre2 = metre.asType(Lenght.class);//semantic problem


On Sun, Nov 2, 2014 at 10:07 PM, Otávio Gonçalves de Santana <
>
 wrote:

> Will be some thing like this:
>
> Quantity<Length> metre = Quantities.getQuantity(BigDecimal.TEN, SI.METRE);
> Quantity<Time> time = Quantities.getQuantity(BigDecimal.TEN, SI.SECOND);
> Quantity<Speed> speed = metre.divide(QuantityOperations.of(time,
> Speed.class));
>
> On Sun, Nov 2, 2014 at 9:53 PM, Werner Keil 
> < >
>  wrote:
>
>> Sorry, but it looks horribly overengineered and artificial[?]
>>
>> People simply want to do
>> Quantity.multiply(Quantity)
>>
>> Not some artificial
>> Quantity.multiply(QuantityOperations)
>>
>> And while Martin must be sleeping now in Asia, I am pretty sure, he
>> recogizes the earlier approach to "trick" the compiler into something 
>> wrong.
>> It just looks far more complicated and not intuitive that way.
>>
>>
>>
>> Werner
>>
>> On Mon, Nov 3, 2014 at 12:38 AM, Otávio Gonçalves de Santana <
>>
>>  wrote:
>>
>>> If we create a model to do this operations:
>>>
>>> /**
>>>  * This interface represents operations to Quantity that needs
>>> verification
>>>  * ( {@link Quantity#divide(Quantity)} and {@link
>>> Quantity#multiply(Quantity)}).
>>>  * @author otaviojava
>>>  *
>>>  * @param <Q> to do the operation with Quantity<Q>
>>>  * @param <E> to verify and cast using Class<E>
>>>  */
>>> public interface QuantityOperations<Q extends Quantity<Q>, E extends
>>> Quantity<E>> {
>>>
>>>     /**
>>>      * The {@link Quantity} to do the operations
>>>      * @return the quantity to operation
>>>      */
>>>     Quantity<Q> getQuantity();
>>>
>>>     /**
>>>      * Class to do the verification
>>>      * @return the Class to verification
>>>      * @see Unit#asType(Class)
>>>      */
>>>     Class<E> getQuantityClass();
>>>
>>> }
>>>
>>>
>>> *In Quantity change the method to:*
>>>
>>> <T extends Quantity<T>, E extends Quantity<E>> Quantity<E>
>>> multipy(QuantityOperations<T, E> operation);
>>>
>>>
>>> *The implementation:*
>>>
>>>     @Override
>>>     public <T extends Quantity<T>, E extends Quantity<E>> Quantity<E>
>>> multipy(QuantityOperations<T, E> operation) {
>>>
>>>         QuantityOperations<T, E> operation = supplier.get();
>>>         return (Quantity<E>) multiply(operation.getQuantity())
>>>                 .asType(operation.getQuantityClass());
>>>
>>>     }
>>>
>>>
>>> I believe this way, we will use the generics and can verify, so everyone
>>> happy [?]
>>>
>>> On Sun, Nov 2, 2014 at 7: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.
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>
>
>
> --
> 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
>
>


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

GIF image

GIF image

GIF image

GIF image



Re: Proposal

(continued)

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

Re: Proposal

Otávio Gonçalves de Santana 11/03/2014

Re: Proposal

Martin Desruisseaux 11/03/2014

Re: Proposal

Martin Desruisseaux 11/03/2014

Re: Proposal

Martin Desruisseaux 11/03/2014

Re: Proposal

Werner Keil 11/03/2014

Re: Proposal

Otávio Gonçalves de Santana 11/17/2014

Re: Proposal

Martin Desruisseaux 11/17/2014

Re: Proposal

Werner Keil 11/17/2014

Re: Proposal

Otávio Gonçalves de Santana 11/17/2014

Re: Proposal

Werner Keil 11/17/2014

Re: Proposal

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