Skip to main content

Re: Proposal

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

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

GIF image

GIF image

GIF image

GIF image



Re: Proposal

(continued)

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

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