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