<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. & 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><?></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<Energy></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