Use Advanced Search to search the entire archive.
Re: Proposal
- From: Werner Keil <
>
- To: "
" <
>
- Subject: Re: Proposal
- Date: Mon, 3 Nov 2014 00:53:55 +0100
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
>
>
Attachment:
35C.gif
Description: GIF image
Attachment:
324.gif
Description: GIF image
Attachment:
330.gif
Description: GIF image
Attachment:
322.gif
Description: GIF image