<p dir="ltr">As long as readInt and friends consume the entire line, I'm fine with that.</p>
<p dir="ltr">I see no value in exit. So many of the students I helped tutor treated that like a crutch, and they had to be dragged away from it. In fact, I think I did too. That is basic control flow that should be treated as unavoidable complexity. Same as basic arithmetic and concatenation.</p>
<p dir="ltr">As for Math, what's stopping us from static importing Math too? No need to reinvent the wheel if it works well enough.</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 15, 2024, 12:00 PM Cay Horstmann <<a href="mailto:cay.horstmann@gmail.com">cay.horstmann@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd like to raise one more time the issue of simple console interaction.<br>
<br>
<a href="https://openjdk.org/jeps/477#Interacting-with-the-console" rel="noreferrer noreferrer" target="_blank">https://openjdk.org/jeps/477#Interacting-with-the-console</a> puts up the strawman of<br>
<br>
try {<br>
     BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));<br>
     String line = reader.readLine();<br>
     ...<br>
} catch (IOException ioe) {<br>
     ...<br>
}<br>
<br>
I don't think it is convincing to cite BufferedReader. I looked up the top five intro to Java books that make up the bulk of US college market. All use Scanner, not BufferedReader. It is easy to see why:<br>
<br>
* No checked exceptions<br>
* Can read numbers<br>
<br>
Scanner has issues (mixing nextInt/nextLine, localized number input vs. non-localized print), so I could, as an author and teacher, be convinced to change to something better.<br>
<br>
The appeal of short print/println/readln methods seems obvious. But now consider number input:<br>
<br>
int age = Integer.parseInt(readln("How old are you?"));<br>
<br>
A beginning student must realize in the first week or so of instruction:<br>
<br>
* There are static and instance methods<br>
* A static method can be<br>
   * qualified by a class<br>
   * unqualified due to static import<br>
   * one of the static methods that is magically imported<br>
     * but only in a source file containing an implicit class<br>
<br>
That's not conceptually simple.<br>
<br>
If the static methods that a beginner needs in the first few weeks (including parseInt, parseDouble, exit, and a handful of the Math methods) were all unqualified, then the beginner would be helped. Otherwise, you would help the beginner more by not statically importing IO by default. They can start out with IO.println, have a consistent mental model in those first few weeks, and learn static imports later.<br>
<br>
Or, if the focus is not the beginner, but the author of small programs, the JEP could state that as the motivation.<br>
<br>
In general, the needs of beginners and authors of small programs are not the same. The JEP bounces between the needs of the two. Implicit classes are useful for both, but magic imports will add puzzlement for beginners.<br>
<br>
Cheers,<br>
<br>
Cay<br>
<br>
--<br>
<br>
Cay S. Horstmann | <a href="https://horstmann.com" rel="noreferrer noreferrer" target="_blank">https://horstmann.com</a><br>
</blockquote></div>