Skip to main content

Proposal

  • From: Jean-Marie Dautelle < >
  • To:
  • Subject: Proposal
  • Date: Sun, 2 Nov 2014 10:50:54 +0100

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.

Attachment: 35C.gif
Description: GIF image

Attachment: 324.gif
Description: GIF image

Attachment: 330.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
 
 
Close
loading
Please Confirm
Close