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 

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




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

Reply via email to