Use Advanced Search to search the entire archive.
Re: Proposal
- From: Jean-Marie Dautelle <
>
- To:
- Subject: Re: Proposal
- Date: Sun, 2 Nov 2014 14:37:11 +0100
Errata: Actually the previous implementation cannot work.
We need to use the proper quantity factory.
<R extends Quantity<R>> R asType(Class<R> type) {
unit.asType(type); // Raises exception if dimension mismatch.
QuantityFactory<R> factory = ...; // Find it (e.g. OSGi service)
return factory.of(value, unit);
}
This is where OSGi can be of tremendous help as users may register new
factories for their custom quantities.
For non-OSGi users, extension is more difficult (mechanisms should be
provided by the RI).
On Sun, Nov 2, 2014 at 2:09 PM, Jean-Marie Dautelle
<
>
wrote:
>
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)
>
--
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