Use Advanced Search to search the entire archive.
Re: Proposal
- From: Werner Keil <
>
- To: "
" <
>
- Subject: Re: Proposal
- Date: Sun, 2 Nov 2014 14:27:39 +0100
With a slight difference, that it returns Quantity<T> we already have this:
<T extends Quantity<T>> Quantity<T> asType(Class<T> type) throws
ClassCastException;
It needs to be shown, best by JUnit tests directly in the API project, that
we can have QuantityFactory return Q, not Quantity<Q> and all operations,
not just specific ones like Length.multiply(Length) work properly. That in
an ME compliant form is the goal, then we could also tweak that method, but
it is already there.
Werner
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)
>
Attachment:
329.gif
Description: GIF image
Attachment:
347.gif
Description: GIF image