<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4" face="monospace">OK, so is this really just that that
      you are bikeshedding the name?  Renaming `input` to `readLine`?  <br>
      <br>
      This is a perfectly reasonable naming choice, of course, but also,
      not what you suggested the first time around:<br>
      <br>
      > ... "a third API" ...<br>
      <br>
      > ... "there are two feasible directions" ...<br>
      <br>
      So what exactly are you suggesting?<br>
      <br>
      <br>
    </font><br>
    <div class="moz-cite-prefix">On 2/18/2024 5:03 PM, Cay Horstmann
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:69a5c417-4f37-4a94-a460-abedb2743791@horstmann.com">Like
      I said, either the scanner methods or the console methods are
      fine.
      <br>
      <br>
      I am of course aware of the utility/complexity of Scanner, and can
      understand the motivation to have a simpler/feebler behavior in
      SimpleIO. Like the one in Console.
      <br>
      <br>
      You don't have to "get a console". A SimpleIO.readLine method can
      just invoke readLine on the system console.
      <br>
      <br>
      My objection is to add yet another "input" method into the mix.
      "input" is weak. Does it read a token or the entire line? Does it
      consume the newline? And if it does just what readLine does, why
      another method name? Because "input" is three characters fewer?
      Let's not count characters.
      <br>
      <br>
      On 18/02/2024 22.43, Brian Goetz wrote:
      <br>
      <blockquote type="cite">I think you are counting characters and
        not counting concepts.
        <br>
        <br>
        Scanner has a ton of complexity in it that can easily trip up
        beginners.  The main sin (though there are others) is that input
        and parsing are complected (e.g., nextInt), which only causes
        more problems (e.g., end of line issues.)   Reading from the
        console is clearly a () -> String operation.  The input()
        method does one thing, which is get a line of text.  That's
        simple.
        <br>
        <br>
        Integer.parseInt (or, soon, patterns that match against string
        and bind an int) also does one thing: convert a string from
        int.  It may seem verbose to have to do both explicitly, but it
        allows each of these operations to be simple, and it is
        perfectly obvious what is going on. On the other hand, Scanner
        is a world of complexity on its own.
        <br>
        <br>
        Console::readLine is nice, but first you have to get a Console.
        ("Why can I print something without having to get some magic
        helper object, but I can't do the same for reading?")  What
        we're optimizing for here is conceptual simplicity; the simplest
        possible input method is the inverse of println.  The fact that
        input has to be validated is a fact of life; we can treat
        validation separately from IO (and we should), and it gets
        simpler when you do.
        <br>
        <br>
        On 2/18/2024 4:12 PM, Cay Horstmann wrote:
        <br>
        <blockquote type="cite">I would like to comment on the
          simplicity of <a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/8323335">https://openjdk.org/jeps/8323335</a> for beginning
          students.
          <br>
          <br>
          I am the author of college texts for introductory programming.
          Like other authors, I introduce the Scanner class (and not
          Console) for reading user input. Given that students already
          know about System.out, it is simpler to call
          <br>
          <br>
          System.out.print("How old are you? ");
          <br>
          int x = in.nextInt(); // in is a Scanner
          <br>
          <br>
          than
          <br>
          <br>
          int x = Integer.parseInt(console.readLine("How old are you?
          "));
          <br>
          <br>
          or with the JEP draft:
          <br>
          <br>
          int x = Integer.parseInt(input("How old are you? "));
          <br>
          <br>
          Then again, having a prompt string is nice too, so I could
          imagine using the Console API with Integer.parseInt and
          Double.parseDouble, instead of Scanner.nextInt/nextDouble.
          <br>
          <br>
          But why have a third API, i.e. "input"?
          <br>
          <br>
          I think there are two feasible directions. Either embrace the
          Scanner API and next/nextInt/nextDouble/nextLine, or the
          Console API and readLine. Adding "input" into the mix is just
          clutter, and ambiguous clutter at that. At least readLine
          makes it clear that the entire line is consumed.
          <br>
          <br>
          Cheers,
          <br>
          <br>
          Cay
          <br>
          <br>
          -- <br>
          <br>
          Cay S. Horstmann |
<a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__http://horstmann.com__;!!ACWV5N9M2RV99hQ!IuXZk_tqIH8rEw1bD3uYb8UcIZF-nnoeFT3UG17pMO5EVXIYVRaAKi7XCq_T02HwnAek1wuV8Wed08w$">https://urldefense.com/v3/__http://horstmann.com__;!!ACWV5N9M2RV99hQ!IuXZk_tqIH8rEw1bD3uYb8UcIZF-nnoeFT3UG17pMO5EVXIYVRaAKi7XCq_T02HwnAek1wuV8Wed08w$</a> 
          | <a class="moz-txt-link-freetext" href="mailto:cay@horstmann.com">mailto:cay@horstmann.com</a>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>