Hi John, Paul, thanks for your reviews - they have helped me polish the code and documentation some more and add some more tests. The result is at http://cr.openjdk.java.net/~mhaupt/8139885/webrev.02
I noticed both of you emphasised how the Streams API helps the implementation - I second that. Streams "made my day" there. :-) I'm replying below to those of your remarks I didn't address in the new webrev. > Am 19.11.2015 um 05:25 schrieb John Rose <john.r.r...@oracle.com>: > My usual practice, though, is to move argument checking and error reporting > code out of line, away from the main logic. I think this is good style, and > it gives the JIT a little bit (a very little bit) of help. In the most generic loop combinator, the tests are somewhat dispersed over the implementation because they depend on results that are not readily available at the beginning of the method's execution. I haven't put them all in one test method because I prefer early failure with clear messages over possibly hard to interpret failure due to inconsistencies in mid-run. > One wishful item: It would be nice if the javadoc examples could be > integrated into JavaDocExamplesTest.java. I see that is messy since we are > now using TestNG instead of JUnit. The point of JavaDocExamplesTest was to > make it easy to "sync" the javadoc with the examples, by having one place to > copy-and-paste the javadoc. I've filed this RFE for that: https://bugs.openjdk.java.net/browse/JDK-8143343 > Am 19.11.2015 um 11:45 schrieb Paul Sandoz <paul.san...@oracle.com>: > I have a mild preference to maintain the 80 char limit for JavaDoc, to me > it’s easier to read. For code i don’t mind a 100 or more limit. The formatting in the files I've touched is inconsistent; I'll stick with the 120 character limit for both code and Javadoc. > 3458 * The loop handle's result type is the same as the sole loop > variable's, i.e., the result type of {@code init}. > > s/variable’s/variable ? No; the genitive is intentional (result type = loop variable type, rather than result type = loop variable). > I guess in the future there may be ample opporunity to specialize the generic > “loop” mechanism with LambdaForms? Yep: https://bugs.openjdk.java.net/browse/JDK-8143211 Best, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
