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: Fri, 17 Oct 2014 03:49:09 +0900
  • Organization: Geomatys

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Le 17/10/14 02:54, Werner Keil a écrit :<br>
    <blockquote
cite="mid:
      "
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">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<img
            src="cid:part1.06060706.02040905@geomatys.fr" goomoji="347"
            style="margin: 0px 0.2ex; vertical-align: middle;"></div>
      </div>
    </blockquote>
    I know it will make a bad impression. But frankly, if this group can
    not perform a logical analysis, we deserve it.<br>
    <br>
    <br>
    <blockquote
cite="mid:
      "
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">We try to be as democratic as
            possible</div>
        </div>
      </div>
    </blockquote>
    But main parts of my argument is about <b>logic</b>! Democracy has
    nothing to do in logic. Do you think that expressions like "<i>if
      A=B and B=C then A=C</i>" 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):<br>
    <br>
    <ol>
      <li><font color="#009900"><b><u>LOGICAL</u> FACT:</b></font> the
        "non-wildcards" proposal, when applied to the specific case of
        the Java language, can not be logically consistent.</li>
      <li><font color="#009900"><b><u>LOGICAL</u> FACT:</b></font> going
        ahead despite the logical problem break the integrity of Java
        parametric type safety.</li>
      <li><font color="#cc0000"><b>OPINION:</b></font> The JSR-363 group
        has no authority for breaking the Java language that way.</li>
    </ol>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote
cite="mid:
      "
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">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.</div>
        </div>
      </div>
    </blockquote>
    Do we agree that SE can use reflection, and that ME take only a
    subset of quantity types?<br>
    <br>
    <br>
    <blockquote
cite="mid:
      "
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">The only place you may refer to is
            the old JSR 275 code as there was no other QuantityFactory
            in the later API:
            <div><a moz-do-not-send="true"
href="https://kenai.com/projects/jsr-275/sources/svn-repository/content/trunk/jsr-275/src/main/java/javax/measure/quantity/QuantityFactory.java?rev=259";>https://kenai.com/projects/jsr-275/sources/svn-repository/content/trunk/jsr-275/src/main/java/javax/measure/quantity/QuantityFactory.java?rev=259</a><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Yes I was thinking about that class. It could be simplified a little
    bit.<br>
    <br>
    <br>
    <blockquote
cite="mid:
      "
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>It returned the interface, but that at the time was
              "crippled", the Quantity had no operations.</div>
          </div>
        </div>
      </div>
    </blockquote>
    We can add the operations, no problem with that.<br>
    <br>
    <br>
    <blockquote
cite="mid:
      "
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> And see JScience 4.x (intended as RI of JSR 275) that
              took Quantity and returned Quantity&lt;?&gt; or
              Quantity&lt;Q&gt; for all relevant operations, not Q<img
                src="cid:part1.06060706.02040905@geomatys.fr"
                goomoji="347" style="margin: 0px 0.2ex; vertical-align:
                middle;"></div>
          </div>
        </div>
      </div>
    </blockquote>
    But nobody proposed to return Q! I explicitly wrote <big><b><tt>Quantity&lt;?&gt;
          multiply(Quantity&lt;?&gt;)</tt></b></big> in my previous
    email! I also wrote "<i>the old method signature was in my opinion
      the best we can achieve</i>". <tt>Energy</tt> is a subtype of <tt>Quantity&lt;Energy&gt;</tt>,
    which is itself assignable to <tt>Quantity&lt;?&gt;</tt>.
    Consequently a <tt>Quantity&lt;?&gt; multiply(Quantity&lt;?&gt;)</tt>
    method can return an instance of <tt>Energy</tt>. No need for
    thousands of methods or methods returning Q.<br>
    <br>
    <br>
    <blockquote
cite="mid:
      "
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">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 <a moz-do-not-send="true"
href="https://github.com/unitsofmeasurement/unit-impl-se/issues?q=is%3Aissue+is%3Aclosed";>https://github.com/unitsofmeasurement/unit-impl-se/issues?q=is%3Aissue+is%3Aclosed</a></div>
        </div>
      </div>
    </blockquote>
    I found no mention of '<tt>asType</tt>' 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 <tt>Quantity.asType(Class)</tt>
    method.<br>
    <br>
    <br>
    <blockquote
cite="mid:
      "
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">Including the problems with asType().
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"><span class="">
                  <blockquote type="cite"> </blockquote>
                </span> I'm sure that this problem does not exist.<span
                  class=""><br>
                </span></div>
            </blockquote>
            <div><br>
            </div>
            <div>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.</div>
          </div>
        </div>
      </div>
    </blockquote>
    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?<br>
    <br>
        Martin<br>
    <br>
  </body>
</html>

Attachment: gifgTEjaU4zxB.gif
Description: GIF image



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

(continued)

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

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