Use Advanced Search to search the entire archive.
Re: Proposal
- From: Werner Keil <
>
- To: "
" <
>
- Subject: Re: Proposal
- Date: Sun, 2 Nov 2014 15:22:18 +0100
I'd certainly use <T> for type, but as this was already in the pipeline, I
reopened
https://java.net/jira/browse/UNITSOFMEASUREMENT-66
We need full proof that it works even in a minimalistic environment like
that Paul and I created for JUnit tests:
https://github.com/unitsofmeasurement/unit-api/tree/master/src/test/java/javax/measure/test/quantity
P.s.: whatever the other names, a QuantityFactory must not declare of(),
except for itself (but we can't do Lambdas in ME for now[?]) so the method
would still be create() whatever it returns.
Werner
On Sun, Nov 2, 2014 at 3:01 PM, Jean-Marie Dautelle
<
>
wrote:
>
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