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 22:08:28 +0200
If they answer I'll share, but unlike Paul and John they asked for it in
German and I don't think anybody else here knows enough German;-)
Their initial feedback was that being type-flexible was preferred, if they
had a serious issue having to cast in their code or wanted operations to
stay in implementations, I'll translate that input.
Regards,
Werner
Am 18.10.2014 21:58 schrieb "Leonardo Lima"
<
>:
>
Werner,
>
>
It would be very good if you forward the eclipse question and answer; or
>
tell us which mailing list did you send the question to.
>
>
If others are interested in our JSR, it's very useful what they have to
>
say.
>
>
Regards,
>
Leonardo.
>
>
Em sábado, 18 de outubro de 2014, Werner Keil
>
<
>
>
escreveu:
>
>
> 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
>
>>
>
>>