Use Advanced Search to search the entire archive.
Re: Proposal
- From: Jean-Marie Dautelle <
>
- To:
- Subject: Re: Proposal
- Date: Sun, 2 Nov 2014 14:09:13 +0100
I think we are getting close but in the Quantities interface we should have
a stronger contract:
public interface Quantity<Q extends Quantity> {
...
<R extends Quantity<R>> R asType(Class<R> cls);
}
QuantityImpl<Q extends Quantity<Q>> implements Quantity<Q> {
double value;
Unit<Q> unit;
<R extends Quantity<R>> R asType(Class<R> type) {
unit.asType(type); // Raises exception if dimension mismatch.
R r = cls.newInstance();
// Since we are using an abstract factory pattern, the following
works for all quantities produced by the same factory.
((QuantityImpl)r).value = value;
((QuantityImpl)r).unit = unit;
return r;
}
}
This allow us to go back to "strong typing" whenever we need it (e.g. to
avoid parameter clashes).
Mass m0 = m1.multiply(m2).divide(m3).asType(Mass.class);
On Sun, Nov 2, 2014 at 1:19 PM, Werner Keil
<
>
wrote:
>
Please see an experimental probe for one of the types that already has
>
full unit test coverage thanks to work by Paul and myself in 0.6
>
>
https://github.com/unitsofmeasurement/unit-api/blob/master/src/main/java/javax/measure/quantity/Length.java
>
>
With test classes
>
>
https://github.com/unitsofmeasurement/unit-api/blob/master/src/test/java/javax/measure/test/quantity/DistanceQuantity.java
>
and
>
>
https://github.com/unitsofmeasurement/unit-api/blob/master/src/test/java/javax/measure/test/quantity/AreaQuantity.java
>
>
Martin is right, it would add dependencies between at least the basic SI
>
types so (which is currently legally impossible anyway, [?]) one could not
>
just pick "Length" from the "quantity" package and implement it without
>
Area, etc.
>
>
Werner
>
>
On Sun, Nov 2, 2014 at 1:11 PM, Jean-Marie Dautelle
>
<
>
>
wrote:
>
>
> > I also assume, you don't want to eliminate the to(Quantity) method from
>
> Quantity, do you?
>
>
>
> Not necessarily. A quantity may be stated in any compatible unit.
>
>
>
> public void wait(Time delay) {
>
> long microseconds = delay.to(MICRO(SECOND)).longValue();
>
> Thread.wait(microseconds);
>
> }
>
>
>
> > WDYT?
>
>
>
> Fully agree, the API should have only interfaces!
>
>
>
>
>
> On Sun, Nov 2, 2014 at 12:50 PM, Werner Keil
>
> <
>
>
> wrote:
>
>
>
>> I also assume, you don't want to eliminate the to(Quantity) method from
>
>> Quantity, do you?
>
>>
>
>> Fowler proposes exactly that signature, though he also leaves it open to
>
>> create a separate Converter element, see JSR 354 simply because you need
>
>> to
>
>> know a lot more for currency conversion like time, date, type (cash,
>
>> card,
>
>> bond, ...) of monetary amount, etc.
>
>> So far we had a fairly simple conversion here, nevertheless typesafe
>
>> thanks to generics.
>
>>
>
>> If only Quantity existed, then like in other cases MeasurementConverter
>
>> (defining the to()) and ValueSupplier would only serve one interface,
>
>> hence
>
>> could logically be merged into Quantity.
>
>>
>
>> If a common understanding is (unlike OpenXC where non-numeric quantities
>
>> are indeed also treated typesafe via a "Unit", but it got no operations on
>
>> the other hand) a multitude or non-numeric quantity would not even have a
>
>> unit, then the current Measurement becomes redundant, as the only purpose
>
>> would be to make these multitudes type-safe, too.
>
>>
>
>> In the interest of an ultra-slim approach for smallest devices (that
>
>> need just a single Unit and Quantity, either from our pre-defined SI stack
>
>> or something completely different)
>
>> could we move the now "orphaned" QuantityFactory and SystemOfUnits into
>
>> SPI (as they have no external dependencies to them in mandatory
>
>> base-types)
>
>> and push UnitConverter up into the root package instead?
>
>>
>
>> This makes us or users more flexible regarding optionality all optional
>
>> packages depend only on the base elements, not even on each other[?]
>
>> And only the root package "javax.measure" contains mandatory core
>
>> elements.
>
>>
>
>> WDYT?
>
>>
>
>> On Sun, Nov 2, 2014 at 12:40 PM, Jean-Marie Dautelle
>
>> <
>
>> > wrote:
>
>>
>
>>> > Do I'm understanding right?
>
>>>
>
>>> Yes 100 %
>
>>>
>
>>> On Sun, Nov 2, 2014 at 12:24 PM, Martin Desruisseaux <
>
>>>
>
>
>>> wrote:
>
>>>
>
>>>> Hello Jean-Marie
>
>>>>
>
>>>> To summarize, you are suggesting three things:
>
>>>>
>
>>>>
>
>>>> 1. Remove the Measurement interface in order to avoid the
>
>>>> conceptual problem with hierarchy.
>
>>>> 2. Define the Quantity interface as a quantitative measurement
>
>>>> (since it contains a value and a unit).
>
>>>> 3. Overload the multiply and divide methods for type safety.
>
>>>>
>
>>>>
>
>>>> Do I'm understanding right?
>
>>>>
>
>>>> Martin
>
>>>>
>
>>>>
>
>>>
>
>>>
>
>>> --
>
>>> 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)
>
>
>
>
--
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:
329.gif
Description: GIF image
Attachment:
347.gif
Description: GIF image