<div dir="auto"><div dir="auto">I can agree with separating the 2 in input. It really helps separate everything down to its primitives.</div><div dir="auto"><br></div><div dir="auto">I have confusion about the method reference.</div><div dir="auto"><br></div><div dir="auto">I tutored 100's of kids from middle schoolers up to post graduate college students. Long story short, most post grads had only heard of method references. Not a single college student I have ever tutored in college has ever been taught about method references, let alone used it in a course. At best, a student who is clearly leading the class decides to do it for fun, since they aren't learning anything to begin with</div><div dir="auto"><br></div><div dir="auto">I am not saying the kids are the final say. I am saying that they are the biggest portion of our target audience. And a vast majority of them will not be able to make use of this.</div><div dir="auto"><br></div><div dir="auto">Putting aside the kids then, the new Java devs that are using this (who also happen to know method references?) are likely not going to gain much from the inclusion of this. At the end of the day, you are swapping a method call with a method reference. What does the method reference give you that you wouldn't get with a method call?</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 21, 2024, 5:05 PM Stephen Colebourne <<a href="mailto:scolebourne@joda.org">scolebourne@joda.org</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 express basic agreement that reading and writing a string<br>
(and not more) is a good first API. But I also agree that it is<br>
potentially an on-ramp to nowhere.<br>
<br>
I'm also not at all happy with `input("How old are you? ")` which is<br>
doing two unrelated things (printing and reading a line)<br>
<br>
<br>
I'd like to throw out a left-field idea to the educators here -<br>
transformation via method reference.<br>
<br>
  printLine("Enter your age");<br>
  int age = readLine(Integer::parseInt);<br>
<br>
Obviously a method reference lambda is not a simple thing to explain<br>
fully, but it is short and direct. Perhaps in the initial learning<br>
stages you can get away without explaining exactly how<br>
Integer::parseInt operates?<br>
<br>
Suggested API:<br>
 public final class SystemIO {<br>
   public static void printLine(Object obj) ...<br>
   public static void print(Object obj) ...<br>
   public static String readLine() throws UncheckedIOException ...<br>
   public static <T> T readLine(Function<String, T> transformer)<br>
throws UncheckedIOException ...<br>
}<br>
<br>
Stephen<br>
<br>
<br>
On Tue, 20 Feb 2024 at 19:32, Cay Horstmann <<a href="mailto:cay@horstmann.com" target="_blank" rel="noreferrer">cay@horstmann.com</a>> wrote:<br>
><br>
> Hi Rémi,<br>
><br>
> I am not bothered by the concepts that Scanner needs, because for me they are reasonable investments. As you point out, they are:<br>
><br>
> * instance methods<br>
> * new<br>
> * import<br>
><br>
> I would switch to a different approach if it (a) didn't introduce yet another fiddly special case (magic static import) and (b) wasn't unreasonably verbose. I would find this too painful:<br>
><br>
> import java.util.SimpleIO;<br>
><br>
> int age = Integer.parseInt(SimpleIO.input("How old are you? "));<br>
><br>
> I could embrace the magic static import if it was sufficiently general and useful to pay for the complexity. Hence my suggestion<br>
><br>
> int age = parseInt(input("How old are you? "));<br>
><br>
> Or<br>
><br>
> int age = readInt("How old are you? ");<br>
><br>
> I need to make these decisions for the books and activities that I produce. As it is in the JEP today, I'd stick with Scanner. I would put in a note, just to signal that I know what is happening,  that as of Java 25 (?), you can also use input, but that it relies on another fiddly rule, and it doesn't transfer to file I/O, so why bother...<br>
><br>
> My sentiment is just a data point. I understand that the cost/benefit model is different for everyone.<br>
><br>
> Cheers,<br>
><br>
> Cay<br>
><br>
> PS. I'd like to register a forceful pushback on "parsing numbers is so crazily complex that we can't possibly deal with it". What does print/println produce for numbers? Is it the crazily complex localized number format? No--only printf applies localization. The print/println methods format numbers as Java literals. That's a settled issue. It's been like that since Java 1.0. Not crazily complex. A readInt/readDouble (or whatever it is called) in SimpleIO can surely be the canonical inverse of print/println.<br>
</blockquote></div>