Use Advanced Search to search the entire archive.
Re: Proposal
- From: Jean-Marie Dautelle <
>
- To:
- Subject: Re: Proposal
- Date: Sun, 2 Nov 2014 12:22:19 +0100
Hi,
I will try to be as succinct as possible.
>
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
No, for the API only a few methods (may be a dozen) will be added (the
methods for which multiply/divide returns an existing predefined quantity).
For the implementation, I would estimate this change to an extra 40 KBytes
maximum, peanuts in term of JAR size, of course I would assume that the
implementation uses a quantity base class with most operations implemented.
>
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().
This could be simplify to
interface QuantityFactory<N extends Number> {
Q extends Quantity<Q> Q valueOf(N, Unit<Q>);
}
But will it compile?
I don't think the would bloat the API. We have only *one* interface with
about 40 convenient methods all using similar naming convention (not the
same as dozens of extra classes)
>
That implies only reducing it to "magnitude" (see
http://en.wikipedia.org/wiki/Quantity) ?
Yes indeed, we don't need the Measurement/MeasurementConverter interface
(unbloating).
>
I assume that's the old nomenclatura from 0,6, or do you propose to keep
that rather than getUnit() or getValue()?
I have no strong feeling about that (what the majority think is best).
I am sure we can converge on something simple, practical, extendable and
user friendly [?]
Cheers,
JM
On Sun, Nov 2, 2014 at 11:40 AM, Werner Keil
<
>
wrote:
>
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
>
--
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:
341.gif
Description: GIF image
Attachment:
B68.gif
Description: GIF image