Skip to main content

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

  • From: Otávio Gonçalves de Santana < >
  • To:
  • Subject: Re: Remove "generic" multiply/divide operations from Quantity
  • Date: Thu, 16 Oct 2014 20:44:26 -0300

@Martin.

    I know generics has some limitations, but still powerfull to do a lot
of things:
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 :)

On Thu, Oct 16, 2014 at 6:49 PM, Jean-Marie Dautelle 
< >
wrote:

> Hi Guys,
> I tred to read through the emails but I failed to understand the question
> !!
> Werner or Martin could you pose the question in simple terms that we can
> all answer by yes or no.
> I am in training all week but I will try to give you my opinion / response.
> Cheers,
> JM
>
> On Thu, Oct 16, 2014 at 10:11 PM, Werner Keil 
> < >
> wrote:
>
>> I left that conclusion ("pruning" of some methods or at least leaving
>> them to implementations like UOMo or JScience did previously) as a possible
>> option.
>> It could be a little inconsistent as to where to apply them. If you had a
>> Quantity type at least you'd need to cast it to SEQuantity (assuming that
>> type exists in an SE specific implementation) or do all of your operations
>>  with SEQuantity<Q> after all. There both
>> multiply(Number) and
>> multiply(SEQuantity) or multiply(Quantity) could still exist.
>>
>> I'll try to phrase a quick question to the interested parties at Eclipse
>> IoT. So far they said they prefer to stay without explicit classes, their
>> response also was against a
>> R multiply(Quantity<T>) because there are so many possible return types.
>>
>> About Martin's question, I can only give one example, but there are at
>> least 50-70 cases in UCUM alone where asType() broke in JDK 8u20 and above.
>> POUND_FORCE was
>> Unit<Force> POUND_FORCE =
>> addUnit(POUND.multiply(ACCELLERATION_OF_FREEFALL).asType(Force.class));
>> but had to become
>> Unit<Force> POUND_FORCE = addUnit(new ProductUnit<Force>(
>> POUND.multiply(ACCELLERATION_OF_FREEFALL)));
>>
>> otherwise the SE port did not compile there any more
>>
>> Thanks,
>> Werner
>>
>> On Thu, Oct 16, 2014 at 9:46 PM, Leonardo Lima 
>> < >
>> wrote:
>>
>>> Hello all.
>>>
>>> As Werner mentioned, I "abstained" from the voting because I understand
>>> (as Otavio also pointed) that this is a more wide problem than our use
>>> cases. API design is not my forte, I'll admit, but I'm keeping up with the
>>> discussion.
>>>
>>> Still, I think it's valid that Martin (or Otavio or even I) write to
>>> OpenJDK and ask about this, specially considering that we would like to be
>>> part of the standard platform. I don't think this would bring bad
>>> impression, au contraire, it should show that we care about what we're
>>> doing specially outside our clique.
>>>
>>> In the end, I understood that:
>>>
>>>    1. What I (really) wanted can't be achieved without "exploding" the
>>>    JSR to have bajilion methods. That's not feasible.
>>>    2. The convenient way to achieve somewhat what I wanted (the
>>>    signature that sparked this thread) breaks Java rules of generics
>>>    expectations. That's Martin's main point.
>>>    3. The best way to continue with Generics is using the <?> and then
>>>    force the API user to cast.
>>>       1. But, then, why not drop it from the signature?
>>>       2. And add signature in JSR 363.1 when better support is
>>>       available in the language?
>>>
>>> Regards,
>>> Leonardo.
>>>
>>> On Thu, Oct 16, 2014 at 4:42 PM, Otávio Gonçalves de Santana <
>>>  >
>>>  wrote:
>>>
>>>> Martin, did you send the email?
>>>> Please go a head.
>>>>  Le 17/10/14 02:54, Werner Keil a écrit :
>>>>
>>>>  Do what you cannot leave, but note, unless either of the Spec Leads
>>>> (Leonardo abstained from the ballot till he gets a better idea of the
>>>> subject/discussion, Jean-Marie has been silent on all of it, maybe he is
>>>> busy or has no opinion?) sanction that, it makes a bad impression of the
>>>> work of the EG[?]
>>>>
>>>> I know it will make a bad impression. But frankly, if this group can
>>>> not perform a logical analysis, we deserve it.
>>>>
>>>>
>>>>   We try to be as democratic as possible
>>>>
>>>> But main parts of my argument is about *logic*! Democracy has nothing
>>>> to do in logic. Do you think that expressions like "*if A=B and B=C
>>>> then A=C*" is a matter of opinion? On which of the following points do
>>>> you disagree? (I explained those points in more details in my first 
>>>> today's
>>>> email):
>>>>
>>>>
>>>>    1. *LOGICAL FACT:* the "non-wildcards" proposal, when applied to
>>>>    the specific case of the Java language, can not be logically 
>>>> consistent.
>>>>    2. *LOGICAL FACT:* going ahead despite the logical problem break
>>>>    the integrity of Java parametric type safety.
>>>>    3. *OPINION:* The JSR-363 group has no authority for breaking the
>>>>    Java language that way.
>>>>
>>>>
>>>> If I'm wrong on point 1 or 2, it should take you only 5 minutes to
>>>> convince me: just point to the logical flaw in the arguments of my first
>>>> today's email.
>>>>
>>>>
>>>>   Otavio changed the Dynamic Proxy version using Reflection in the SE
>>>> port. And given there is no Reflection in ME 8, most of it also got 
>>>> applied
>>>> to RI.
>>>>
>>>> Do we agree that SE can use reflection, and that ME take only a subset
>>>> of quantity types?
>>>>
>>>>
>>>>   The only place you may refer to is the old JSR 275 code as there was
>>>> no other QuantityFactory in the later API:
>>>>
>>>> https://kenai.com/projects/jsr-275/sources/svn-repository/content/trunk/jsr-275/src/main/java/javax/measure/quantity/QuantityFactory.java?rev=259
>>>>
>>>> Yes I was thinking about that class. It could be simplified a little
>>>> bit.
>>>>
>>>>
>>>>   It returned the interface, but that at the time was "crippled", the
>>>> Quantity had no operations.
>>>>
>>>> We can add the operations, no problem with that.
>>>>
>>>>
>>>>    And see JScience 4.x (intended as RI of JSR 275) that took Quantity
>>>> and returned Quantity<?> or Quantity<Q> for all relevant operations, not 
>>>> Q
>>>> [?]
>>>>
>>>> But nobody proposed to return Q! I explicitly wrote *Quantity<?>
>>>> multiply(Quantity<?>)* in my previous email! I also wrote "*the old
>>>> method signature was in my opinion the best we can achieve*". Energy
>>>> is a subtype of Quantity<Energy>, which is itself assignable to
>>>> Quantity<?>. Consequently a Quantity<?> multiply(Quantity<?>) method
>>>> can return an instance of Energy. No need for thousands of methods or
>>>> methods returning Q.
>>>>
>>>>
>>>>   We cannot do a "diff" between all unit systems, especially US or
>>>> UCUM here, but if you do that diff, you'll see all the places that 
>>>> asType()
>>>> simply broke the code starting with SE 8u20. Also look at SE port issues,
>>>> especially all
>>>> https://github.com/unitsofmeasurement/unit-impl-se/issues?q=is%3Aissue+is%3Aclosed
>>>>
>>>> I found no mention of 'asType' under that link and by browsing in the
>>>> comments, but maybe I didn't looked hard enough. Anyway this is not the
>>>> main issue, since we are not proposing a Quantity.asType(Class) method.
>>>>
>>>>
>>>>   Including the problems with asType().
>>>>>
>>>>>   I'm sure that this problem does not exist.
>>>>>
>>>>
>>>>  It does, see above, in the SE 8 implementation there are very few
>>>> cases where asType() did not break the code and it seems the remedy could
>>>> be used to replace all existing calls.
>>>>
>>>> Then, please point me to a place where it broke the code. Is it
>>>> possible to give me something more accurate than digging in the history 
>>>> of
>>>> the entire project?
>>>>
>>>>     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)
>



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

GIF image



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

(continued)

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

Werner Keil 10/16/2014

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

Martin Desruisseaux 10/16/2014

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

Werner Keil 10/16/2014

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

Martin Desruisseaux 10/16/2014

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

Werner Keil 10/16/2014

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

Martin Desruisseaux 10/16/2014

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

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

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

Leonardo Lima 10/16/2014

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

Werner Keil 10/16/2014

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

Jean-Marie Dautelle 10/16/2014

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

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

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
 
 
Close
loading
Please Confirm
Close