Skip to main content

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

  • From: Leonardo Lima < >
  • To: " " < >
  • Subject: Re: Remove "generic" multiply/divide operations from Quantity
  • Date: Thu, 16 Oct 2014 16:46:44 -0300

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

GIF image



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

(continued)

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

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

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