Use Advanced Search to search the entire archive.
Re: Proposal
- From: Otávio Gonçalves de Santana <
>
- To:
- Subject: Re: Proposal
- Date: Sun, 2 Nov 2014 22:07:40 -0200
Will be some thing like this:
Quantity<Length> metre = Quantities.getQuantity(BigDecimal.TEN, SI.METRE);
Quantity<Time> time = Quantities.getQuantity(BigDecimal.TEN, SI.SECOND);
Quantity<Speed> speed = metre.divide(QuantityOperations.of(time,
Speed.class));
On Sun, Nov 2, 2014 at 9:53 PM, Werner Keil
<
>
wrote:
>
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
>
>
>
>
>
--
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



