Use Advanced Search to search the entire archive.
Re: Remove "generic" multiply/divide operations from Quantity
- From: Werner Keil <
>
- To:
- Subject: Re: Remove "generic" multiply/divide operations from Quantity
- Date: Sat, 18 Oct 2014 15:01:30 +0200
Besides, if we pruned all <?> Quantity methods, we would have to do the
same to Unit!;-)
The problem is not the numeric value, that is always calculated right, only
subject to formatting if needed. The problem also to display properly in
the right target type is Unit.multiply(Unit). The Quantity method is mostly
a convenience to do this for both, but the real issue lies in Unit.
A SmartHomeDemo I wrote shows this, see uom-demos.
Werner
Am 18.10.2014 14:33 schrieb "Werner Keil"
<
>:
>
Martin/Jean-Marie/all,
>
>
Do you want this now, too?;-)
>
>
I did not hear from Eclipse, but unless they say "do it like 0.6 get rid
>
of all operations", not sure if they'd still fancy using JSR 363 then?;-O
>
Am 18.10.2014 14:09 schrieb "Otávio Gonçalves de Santana" <
>
>:
>
>
> Thank you Leonardo, to explain better.
>
> Considering we need to take care the semantic, I agree with Leonardo to
>
> remove and wait to Generic the maturity to go back again.
>
>
>
> On Fri, Oct 17, 2014 at 8:49 AM, Leonardo Lima
>
> <
>
>
> wrote:
>
>
>
>> Hello, all!
>
>>
>
>> It seems that the best way out is to leave the operations that change
>
>> unit (inverse, multiply, divide) out of scope and wait until there's
>
>> better
>
>> support for this in the Java APIs. This because once we add a method, we
>
>> (almost) can't remove it from the API; but we can always add new ones.
>
>>
>
>> I understand that the <?> method is the best one if we want to keep the
>
>> operations in the API, as it's the most explicit about what's happening: I
>
>> don't know what's coming out from the method call.
>
>>
>
>> About size and Java ME, the problem arises when vendors start supporting
>
>> and say they already include this JSR in their Java stack. Used as a
>
>> library, we can (and do) strip and obfuscate methods and classes to reduce
>
>> size (and protect IP). But that won't be the case for a vendor that
>
>> supports the JSR, as they should support the spec as a whole. Given this,
>
>> I
>
>> support the "optionality" of Quantities, because it makes no sense for a
>
>> temperature sensor vendor to support speed and unrelated units. They
>
>> declare what Quantities they support and/or support it via proprietary API
>
>> (like the BMI interface Werner used as an example).
>
>>
>
>> Lastly I don't agree that just because the JDK currently has "improper
>
>> code" we're allowed to do the same. I think we should consult the OpenJDK
>
>> and Java ME people if we ever want this to become part of the respective
>
>> platforms (even when this is not stated in the JSR proposal).
>
>>
>
>> Regards,
>
>> Leonardo.
>
>>
>
>> On Thu, Oct 16, 2014 at 11:06 PM, Otávio Gonçalves de Santana <
>
>>
>
>
>> wrote:
>
>>
>
>>> Martin.
>
>>> Is there any place in the new JavaSE API that does something like you
>
>>> propose to do?
>
>>>
>
>>>
>
>>> On Thu, Oct 16, 2014 at 10:03 PM, Martin Desruisseaux <
>
>>>
>
>
>>> wrote:
>
>>>
>
>>>> Otavio, all the JDK examples you gave below are *safe*, because:
>
>>>>
>
>>>> - In an empty list/set/map, the type of elements (Integer, String,
>
>>>> etc.) become irrelevant.
>
>>>> - In asList, the relationship between input and output types is
>
>>>> correctly expressed. The method signature:
>
>>>>
>
>>>> <T> List<T> asList(T... a)
>
>>>>
>
>>>> said: "*the type of elements in the list is the same than the type
>
>>>> of the given elements*", which is correct.
>
>>>>
>
>>>> By contract, UNITSOFMEASUREMENT-62 is *unsafe*. The following method
>
>>>> signature:
>
>>>>
>
>>>> <T extends Quantity<T>,R extends Quantity<R>> Quantity<R>
>
>>>> multiply(Quantity<T> that)
>
>>>>
>
>>>> said: "*there is no relationship between the type of this instance
>
>>>> Q, the input type T and the output type R*" (otherwise, please show
>
>>>> me where the relationship is expressed). The fact that this signature
>
>>>> declares no relationship is why the compiler accepts anything like "mass
>
>>>> = length.multiply(time)". This method signature is wrong - the
>
>>>> reality is not an absence of relationship. The reality is a relationship
>
>>>> that we can not express in Java.
>
>>>>
>
>>>>
>
>>>> Martin
>
>>>>
>
>>>>
>
>>>> Le 17/10/14 08:44, Otávio Gonçalves de Santana a écrit :
>
>>>>
>
>>>> About the question of Martin, Yes we can do and there are in in SE api
>
>>>> such java.util.Collections
>
>>>> <http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html>,
>
>>>> java.util.Arrays
>
>>>> <http://docs.oracle.com/javase/7/docs/api/java/util/Arrays.html>,
>
>>>> etc.
>
>>>>
>
>>>> List<Integer> intergers = Collections.emptyList();
>
>>>> List<String> strings = Collections.emptyList();
>
>>>>
>
>>>> java.util.Set<Integer> intergersSet = Collections.emptySet();
>
>>>> java.util.Set<String> stringsSet = Collections.emptySet();
>
>>>>
>
>>>> java.util.Map<String, Integer> map = Collections.emptyMap();
>
>>>> java.util.Map<String, String> map2 = Collections.emptyMap();
>
>>>>
>
>>>> List<Long> longs = java.util.Arrays.asList(1L, 2L, 3L);
>
>>>> List<Integer> ints = java.util.Arrays.asList(1, 2, 4);
>
>>>>
>
>>>>
>
>>>> I can do something like this and still the Java language :)
>
>>>>
>
>>>>
>
>>>>
>
>>>
>
>>>
>
>>> --
>
>>> Otávio Gonçalves de Santana
>
>>>
>
>>> blog: http://otaviosantana.blogspot.com.br/
>
>>> twitter: http://twitter.com/otaviojava
>
>>> site: *http://about.me/otaviojava <http://about.me/otaviojava>*
>
>>> 55 (11) 98255-3513
>
>>>
>
>>>
>
>>
>
>
>
>
>
> --
>
> Otávio Gonçalves de Santana
>
>
>
> blog: http://otaviosantana.blogspot.com.br/
>
> twitter: http://twitter.com/otaviojava
>
> site: *http://about.me/otaviojava <http://about.me/otaviojava>*
>
> 55 (11) 98255-3513
>
>
>
>