Use Advanced Search to search the entire archive.
Re: Proposal
- From: Werner Keil <
>
- To: "
" <
>
- Subject: Re: Proposal
- Date: Sun, 2 Nov 2014 11:40:05 +0100
Hi,
Answers inline
Am 02.11.2014 10:51 schrieb "Jean-Marie Dautelle"
<
>:
>
>
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.
>
While the current layout declares a "quantity" package optional, we would
end up with a much bigger JAR (hence split from "core"/"base" quite
inevitable;-) and in any case a giant wormhole TCK;-O
Currently this is subject to implementations. Unit tests in the API created
with Paul's help in the 0.6 stage demonstrate it.
>
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>);
>
...
>
}
Why massOf(Lenght)?;-)
Again, if we agreed on keeping it optional in a bundle like SPI that could
work but it feels horribly bloated, worse than 310 which only got
ofNanos(), ofMillis() or of years().
>
>
// Unit RI
>
abstract class Quantities {
>
public static QuantityFactory DOUBLE = ...;
>
public static QuantityFactory BIG_DECIMAL = ...;
>
}
Hiding these behind a service could be cleaner, but it is up to
implementations.
>
>
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 )
>
The likes of Groovy or Scala partly used that naming. In Java only JSR 310
did some weird and totally uncommon mix of addTo(), plus(), dividedBy() or
times(), from different interfaces / concrete classes. Neither naming nor
overloading was done well in 310 and you see the horrible method bloating
by minusDays(),...
I have the feeling we could end up with something like
Area = timesLength(Length) or
Volume = timesArea(Area), too, [?]
>
There is no need for a Measurement class (and MeasurementConverter).
That implies only reducing it to "magnitude" (see
http://en.wikipedia.org/wiki/Quantity) ?
As Martin asked earlier, what an enum would do when implementing Quantity,
well in the current design it implements Measurement, the "abstract
quantity", not Quantity which reflects "magnitude" or "numeric quantity".
While it uses a fairly strange relationship between Unit and Quantity,
leaving that aside, I must say, OpenXC solved that pretty well:
http://android.openxcplatform.com/reference/com/openxc/units/Unit.html
- Quantity is a Numeric quantity, hence it even allows only numbers to
instanciate (could chose between e.g. Double and BigDecimal if you want)
- State is the "multitude" based on an Enum but also inheriting from what
OpenXC calls Unit.
- Boolean for simple On/Off cases, meaning even they are typed by OpenXC,
so you know the unit for "ignition" opposed to "lights" or similar.
While I am not sure, if we should offer 3 similar detail types (OpenXC uses
concrete classes for almost everything) it would be good to at least offer
the choice. Otherwise many use cases in Embedded, not just Automotive could
be locked out and left to create yet their own API.
>
>
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>);
>
...
>
}
I assume that's the old nomenclatura from 0,6, or do you propose to keep
that rather than getUnit() or getValue()?
>
>
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.
Regards,
Werner
Attachment:
341.gif
Description: GIF image