SimpleIO in JEP draft 8323335

[David Alayachew]

I will say, if we really want the input method, then it might make more
sense if it was called prompt. And then, we can use input to just read a
line from the user, and prompt to do the combination of writing a line and
then reading a line.

On Wed, Feb 21, 2024, 5:34 PM David Alayachew <davidalayachew at gmail.com>
wrote:

> I can agree with separating the 2 in input. It really helps separate
> everything down to its primitives.
>
> I have confusion about the method reference.
>
> 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
>
> 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.
>
> 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?
>
>
> On Wed, Feb 21, 2024, 5:05 PM Stephen Colebourne <scolebourne at joda.org>
> wrote:
>
>> I'd like to express basic agreement that reading and writing a string
>> (and not more) is a good first API. But I also agree that it is
>> potentially an on-ramp to nowhere.
>>
>> I'm also not at all happy with `input("How old are you? ")` which is
>> doing two unrelated things (printing and reading a line)
>>
>>
>> I'd like to throw out a left-field idea to the educators here -
>> transformation via method reference.
>>
>>   printLine("Enter your age");
>>   int age = readLine(Integer::parseInt);
>>
>> Obviously a method reference lambda is not a simple thing to explain
>> fully, but it is short and direct. Perhaps in the initial learning
>> stages you can get away without explaining exactly how
>> Integer::parseInt operates?
>>
>> Suggested API:
>>  public final class SystemIO {
>>    public static void printLine(Object obj) ...
>>    public static void print(Object obj) ...
>>    public static String readLine() throws UncheckedIOException ...
>>    public static <T> T readLine(Function<String, T> transformer)
>> throws UncheckedIOException ...
>> }
>>
>> Stephen
>>
>>
>> On Tue, 20 Feb 2024 at 19:32, Cay Horstmann <cay at horstmann.com> wrote:
>> >
>> > Hi Rémi,
>> >
>> > I am not bothered by the concepts that Scanner needs, because for me
>> they are reasonable investments. As you point out, they are:
>> >
>> > * instance methods
>> > * new
>> > * import
>> >
>> > 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:
>> >
>> > import java.util.SimpleIO;
>> >
>> > int age = Integer.parseInt(SimpleIO.input("How old are you? "));
>> >
>> > I could embrace the magic static import if it was sufficiently general
>> and useful to pay for the complexity. Hence my suggestion
>> >
>> > int age = parseInt(input("How old are you? "));
>> >
>> > Or
>> >
>> > int age = readInt("How old are you? ");
>> >
>> > 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...
>> >
>> > My sentiment is just a data point. I understand that the cost/benefit
>> model is different for everyone.
>> >
>> > Cheers,
>> >
>> > Cay
>> >
>> > 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240221/8dc7efba/attachment-0001.htm>