Skip to main content

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
>>>
>>>


Re: Remove "generic" multiply/divide operations from Quantity

(continued)

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/17/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/17/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/17/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Leonardo Lima 10/17/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Leonardo Lima 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Otávio Gonçalves de Santana 10/18/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/19/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/19/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/19/2014

Re: Remove "generic" multiply/divide operations from Quantity

Jean-Marie Dautelle 10/19/2014

Re: Remove "generic" multiply/divide operations from Quantity

Martin Desruisseaux 10/19/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/19/2014

Re: Remove "generic" multiply/divide operations from Quantity

Werner Keil 10/19/2014
 
 
Close
loading
Please Confirm
Close