Skip to main content

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

  • From: Martin Desruisseaux < >
  • To:
  • Subject: Re: Remove "generic" multiply/divide operations from Quantity
  • Date: Thu, 16 Oct 2014 15:53:01 +0900
  • Organization: Geomatys

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Hello all</p>
    <p>
    </p>
    <p>
      I feel hesitation in participating to this doodle, since it seems
      a non-sense to me. It is not a matter of democracy or opinion. The
      proposed non-wildcards signature is a violation of the laws of
      logic. To me, this pool is like asking "<i>would you like 2+2 to
        be equal to 4 or to something else?</i>" and praising the virtue
      of democracy in answering that question. Even if thousands of
      "domain experts" vote for 2+2=5, it is still wrong.</p>
    <p>
    </p>
    <p>
      Java parameterized type syntax is a kind of mathematical function
      that establish a mapping between class type, method argument type
      and return type. The universe of possible relationships is
      practically infinite, but Java syntax can express only the
      following:</p>
    <ul>
      <li>Same type</li>
      <li>Subtype</li>
      <li>Super-type</li>
    </ul>
    <p>Any other kind of relationship can not be expressed in Java. Note
      that this is a limitation of the Java language, not a logical
      restriction, as other languages have more capabilities. For
      example C++ templates allow arithmetic operations on parameterized
      types (a "type" in C++ can be a compile-time numerical value).
      With C++ capabilities, Otavio's wish could be fulfilled (see
      Barton J. &amp; al., 1994, <u>Scientific and Engineering C++</u>,
      Addison-Wesley - they have done exactly that 20 years ago).<br>
    </p>
    <p>
    </p>
    <p>Given the above Java limitation, <b>no matter how we turn the
        problem around, there is absolutely no way to express the type
        result of an arithmetic operation in the Java language.</b> It
      is simply impossible, because the relationship between input and
      output types is not one of the above-cited supported
      relationships. <b>Werner, can you understand that this is logic,
        not opinion?</b><br>
    </p>
    <p>What Otavio wants to do has been solved at least 20 years ago.
      But it requires arithmetic operations on parameterized types,
      which is possible in C++ but not in Java. Consequently, in our
      case the <tt>&lt;?&gt;</tt> wildcard does not mean "bad design".
      It means "<i>result is outside the scope of what we can express in
        Java</i>".<br>
    </p>
    <p>Bloch"s "Effective Java" book said (emphasis is mine):<br>
    </p>
    <blockquote>
      <p>Eliminate every unchecked warnings that you can. (...)  If the
        warning cannot be eliminated, <b>and you can prove the code is
          safe</b>, then you can use a <tt>@SuppressWarnings("unchecked")</tt>
        annotation to eliminate the warning. When using <tt>@SuppressWarnings("unchecked")</tt>
        annotation, <b>you must comment why it is correct and safe</b>.<br>
      </p>
    </blockquote>
    <p>We can not prove that the <tt>multiply</tt>, <tt>divide</tt>, <tt>inverse</tt>
      and <tt>pow</tt> code are safe in current Java - as explained
      above, it is impossible. Consequently we shall not suppress the
      warnings. The only clean way to suppress the warnings is to cast
      to e.g. <tt>Energy</tt> instead than <tt>Quantity&lt;Energy&gt;</tt>
      in user code. This is the only safe path I can see (except <tt>asType(Class)</tt>).
      If such casting is still considered too annoying, then we could
      consider removing completely parameterized type, so casting would
      not be needed anymore. Indeed, the UNITSOFMEASUREMENT-62 proposal
      is a complicated way to said "<i>behave here as if parameterized
        type did not existed</i>". It does <b>not</b> express the real
      relationship between argument and return type, and is <b><u>logically</u>
        impossible</b> to implement safely in Java.<br>
    </p>
    <p>I can not understand why some developers stay blind in front of
      the law of logic. Again, I'm not pushing for my own opinion - I'm
      trying to explain that 2+2=4 and that we can not accept to said "<i>oh
        well, let accept 2+2=5 or 6 or 7 here for the sake of
        convenience</i>". I feel so desperate that I'm considering to
      send email to <tt><a class="moz-txt-link-abbreviated" href="mailto:
      ">
      </a></tt> asking for
      rescue, since they were some talk about possible inclusion of
      JSR-363 in the JDK. I have no doubt that many would be horrified
      by the idea of "lying parameterized types".<br>
    </p>
    <p>    Martin<br>
    </p>
    <p><br>
    </p>
    <p>
    </p>
    <p>
    </p>
    <div class="moz-cite-prefix">Le 14/10/14 06:59, Werner Keil a
      écrit :<br>
    </div>
    <blockquote
cite="mid:
      "
      type="cite">
      <div dir="ltr">All,
        <div><br>
        </div>
        <div>I sent a doodle out to ever EG member (by name, not to the
          list, as it would not go through)</div>
        <div>Only one choice per participant is allowed, that makes
          sense here, since it is pretty much a </div>
        <div>"Cast and wildcard vs. non-wildcard Generic" (of course
          users can also pass the result into a "wildcard" variable or
          use it as argument as long as it involves Quantity)</div>
        <div><br>
        </div>
        <div>Please submit your choice, then we know who has what
          preference. If feasable (after next Mon evening I should be in
          a hotel again with Wifi, hopefully stable to join Hangout,
          Skype, etc.) we could have a more detailed discussion, but so
          far it is important that every EG member who has an opinion
          declares it here. Not just Otavio and Martin (with occasional
          input by Leo or me<img
            src="cid:part1.09020909.05000507@geomatys.fr" goomoji="329"
            style="margin: 0px 0.2ex; vertical-align: middle;">)
          Everyone including Spec Leads should vote. If necessary and
          all 3 Spec Leads participate, 2 out of 3 would be a majority
          in the end<img src="cid:part1.09020909.05000507@geomatys.fr"
            goomoji="329" style="margin: 0px 0.2ex; vertical-align:
            middle;"> Spec Leads ultimately shall decide, in some cases
          and other JSRs they rarely care to ask others, here we try to
          work transparent and democratic.</div>
        <div><br>
        </div>
        <div>And during recent  F2F e.g. Heather also noted activity
          like this on the mailing lists as positive<img
            src="cid:part3.04020204.09010209@geomatys.fr" goomoji="330"
            style="margin: 0px 0.2ex; vertical-align: middle;"></div>
        <div><br>
        </div>
        <div>Regards,</div>
        <div>Werner</div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

Attachment: gifsMbUEZMfMC.gif
Description: GIF image

Attachment: gifwt7rxSmon3.gif
Description: GIF image



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

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

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

Werner Keil 10/01/2014

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

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

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

Werner Keil 10/01/2014

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

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

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

Werner Keil 10/01/2014

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

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

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

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

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

Martin Desruisseaux 10/12/2014

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

Werner Keil 10/13/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

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