SimpleIO in JEP draft 8323335

[Brian Goetz]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240218/0fedd1b9/attachment-0001.htm>