<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<?> or Quantity<Q> 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<?> multiply(Quantity<?>)</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<Energy></tt>, which is itself assignable to <tt>Quantity<?></tt>. Consequently a <tt>Quantity<?> multiply(Quantity<?>)</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