Use Advanced Search to search the entire archive.
Re: Proposal
- From: Jean-Marie Dautelle <
>
- To:
- Subject: Re: Proposal
- Date: Sun, 2 Nov 2014 15:01:21 +0100
For ME the following implementation should work (no reflection and no OSGi
services):
In Unit-API
interface QuantityFactory<N extends Number, Q extends Quantity<Q>> {
Class<N> getValueType();
Class<Q> getQuantityType();
Q of(N value, Unit<Q>);
}
In RI:
abstract class Quantities { // Double implementation.
public static <Q extends Quantity<Q>> void
setFactory(QuantityFactory<Double, Q>, Class<Q>) { ... } // Allows for
custom registration.
public static <Q extends Quantity<Q>> QuantityFactory<Double, Q>
getFactory(Class<Q>)
{ ... }
public static QuantityFactory<Double, Mass.class> MASS =
getFactory(Mass.class);
public static QuantityFactory<Double, Length.class> LENGTH =
getFactory(Length.class);
...
}
class QuantityImpl<Q extends Quantity<Q>> implements Quantity<Q> {
...
<R extends Quantity<R>> R asType(Class<R> type) {
unit.asType(type); // Raises exception if dimension mismatch.
QuantityFactory<Double, R> factory = Quantities.getFactory(type);
return factory.of(value, unit);
}
}
On Sun, Nov 2, 2014 at 2:37 PM, Jean-Marie Dautelle
<
>
wrote:
>
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)
>
--
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