New candidate JEP: 445: Flexible Main Methods and Anonymous Main Classes (Preview)

[Holo The Sage Wolf]

Is having the "standard" names with default static important really painful?

To me it seems like a non-issue, to get confused you would need to use
static methods, so people who have static important to e.g. a printStream
instance won't be effected, which I imagine is the vast majority of cases.

But even people who do have such utility class, I would imagine that the IO
class would just delegate some printer and scanner behind the scenes, so
people would be able to migrate they classes into the IO class.

--

I'll add that even if it is a bigger deal than I think, I find having the
standard names but no default static important preferable over having
different names but statically important

On Tue, Apr 11, 2023, 10:28 Remi Forax <forax at univ-mlv.fr> wrote:

> ----- Original Message -----
> > From: "cay horstmann" <cay.horstmann at gmail.com>
> > To: "jdk-dev" <jdk-dev at openjdk.org>
> > Sent: Tuesday, April 11, 2023 9:00:46 AM
> > Subject: Re: New candidate JEP: 445: Flexible Main Methods and Anonymous
> Main Classes (Preview)
>
> > On 11/04/2023 08.41, Remi Forax wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "cay horstmann" <cay.horstmann at gmail.com>
> >>> To: "jdk-dev" <jdk-dev at openjdk.org>
> >>> Sent: Tuesday, April 11, 2023 8:13:02 AM
> >>> Subject: Re: New candidate JEP: 445: Flexible Main Methods and
> Anonymous Main
> >>> Classes (Preview)
> >>
> >>> ...
> >>> I agree that System.out.println is a problem. I always am troubled by
> having to
> >>> explain, in Chapter 2, the difference between
> >>>
> >>> 1. Scanner in = new Scanner(System.in); // static variable in
> constructor
> >>> 2. int n = in.nextInt(); // instance method
> >>> 3. double x = Math.sqrt(n); // static method
> >>> 3. System.out.println(...); // instance method invoked on static
> variable
> >>>
> >>> One way of addressing that problem would be an App class with methods
> nextInt,
> >>> println, sqrt, and so on, which an anonymous class automatically
> extends. But
> >>> that can't be retrofitted to this JEP at a later date. For that
> reason, I would
> >>> like to see the proposed solution for beginner-friendly console I/O.
> >>
> >> yes, a class "IO" is the next step
> >>
> >>    int number = IO.scanInt();
> >>    IO.log(number);
> >>
> >> with the idea that maybe there is an "import static java.lang.IO.*;" by
> default
> >> (if it doe not clash with other explicit static imports) so the code
> can be
> >> simplified to
> >>
> >>    int number = scanInt();
> >>    log(number);
> >>
> > I am fine with a class IO with static methods since I already need to
> teach
> > static Math methods. It would be helpful if the method names were the
> same as
> > for Scanner and PrintStream, i.e. nextInt, nextDouble, nextLine, next,
> println,
> > print, printf.
> >
> > I don't think default imports are necessary. Whenever I suggested to use
> import
> > static java.lang.Math.*; instructors stared at me blankly. There seemed
> no
> > objection to Math.sqrt, so IO.println would probably be ok as well.
>
> The names depends on the capability to do a default static import or not.
> If we choose the route of default static import, we need names that will
> not collide too often with names that are usually statically imported.
>
> Otherwise, yes, if there is no default static import, IO.println() is
> better name than IO.log().
>
> >
> > Cheers,
> >
> > Cay
>
> regards,
> Rémi
>
> >
> > --
> >
> > Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230411/b152cbda/attachment-0001.htm>