SimpleIO in JEP draft 8323335

[Cay Horstmann]

Yes, that's what I am saying. If scanners live in vain, stick with a subset of the Console methods. Use its readLine. Make it so that SimpleIO uses System.console(). And add print and println to Console.

The JEP talks about being able to start programming without having to know about static methods. How does a beginner read a number? With Integer.parseInt(readLine(prompt))?

What about locales? Is print/println localized? Console.printf is. If so, how are beginners from around the world supposed to read localized numbers? With NumberFormat.getInstance().parse(readLine(prompt))?

Adding localized readInt/readDouble to SimpleIO might do the trick. Do they consume the trailing newline? (The equivalent Scanner methods don't, which is definitely a sharp edge for beginners.)

On 18/02/2024 23.08, Brian Goetz wrote:
> OK, so is this really just that that you are bikeshedding the name?  Renaming `input` to `readLine`?
> 
> This is a perfectly reasonable naming choice, of course, but also, not what you suggested the first time around:
> 
>  > ... "a third API" ...
> 
>  > ... "there are two feasible directions" ...
> 
> So what exactly are you suggesting?
> 
> 
> 
> On 2/18/2024 5:03 PM, Cay Horstmann wrote:
>> Like I said, either the scanner methods or the console methods are fine.
>>
>> 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.
>>
>> You don't have to "get a console". A SimpleIO.readLine method can just invoke readLine on the system console.
>>
>> 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.
>>
>> On 18/02/2024 22.43, Brian Goetz wrote:
>>> I think you are counting characters and not counting concepts.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> On 2/18/2024 4:12 PM, Cay Horstmann wrote:
>>>> I would like to comment on the simplicity of https://openjdk.org/jeps/8323335 for beginning students.
>>>>
>>>> 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
>>>>
>>>> System.out.print("How old are you? ");
>>>> int x = in.nextInt(); // in is a Scanner
>>>>
>>>> than
>>>>
>>>> int x = Integer.parseInt(console.readLine("How old are you? "));
>>>>
>>>> or with the JEP draft:
>>>>
>>>> int x = Integer.parseInt(input("How old are you? "));
>>>>
>>>> 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.
>>>>
>>>> But why have a third API, i.e. "input"?
>>>>
>>>> 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.
>>>>
>>>> Cheers,
>>>>
>>>> Cay
>>>>
>>>> -- 
>>>>
>>>> Cay S. Horstmann | https://urldefense.com/v3/__http://horstmann.com__;!!ACWV5N9M2RV99hQ!IuXZk_tqIH8rEw1bD3uYb8UcIZF-nnoeFT3UG17pMO5EVXIYVRaAKi7XCq_T02HwnAek1wuV8Wed08w$ | mailto:cay at horstmann.com
>>>
>>
> 

-- 

--

Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com