Skip to main content

Re: Proposal

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

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

GIF image

GIF image

GIF image



Re: Proposal

(continued)

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

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