Use Advanced Search to search the entire archive.
Re: Proposal
- From: Jean-Marie Dautelle <
>
- To:
- Subject: Re: Proposal
- Date: Sun, 2 Nov 2014 11:15:02 +0100
Or better:
// Unit-API
interface QuantityFactory<N extends Number> {
Length lengthOf(N, Unit<Length>);
Mass massOf(N, Unit<Length>);
...
}
// Unit RI
abstract class Quantities {
public static QuantityFactory<Double> DOUBLE = ...;
public static QuantityFactory<BigDecimal> BIG_DECIMAL = ...;
}
On Sun, Nov 2, 2014 at 11:11 AM, Jean-Marie Dautelle
<
>
wrote:
>
Erratum:
>
>
/ Unit-API
>
interface QuantityFactory {
>
Length lengthOf(Number, Unit<Length>);
>
Mass massOf(Number, Unit<Length>);
>
...
>
}
>
>
>
On Sun, Nov 2, 2014 at 10: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.
>
>
>
>
>
>
--
>
It is not the strongest of the species that survives, nor the most
>
intelligent. It is the one that is most adaptable to change. - Darwin's
>
Origin of Species (digest)
>
--
It is not the strongest of the species that survives, nor the most
intelligent. It is the one that is most adaptable to change. - Darwin's
Origin of Species (digest)
Attachment:
35C.gif
Description: GIF image
Attachment:
324.gif
Description: GIF image
Attachment:
330.gif
Description: GIF image