New candidate JEP: 463: Implicit Classes and Instance Main Methods (Second Preview)

[David Alayachew]

Hello Maurizio,

Thank you for your response!

Yeah, I see now how my suggestions don't work out. Ultimately, my
suggestions force us to think of things with a "beginner" version that
doesn't align with the way things would go later. Like you mentioned with a
program working with one method, but not 2. Or having one called run and
another called main that just so happens to take a String[] parameter.

Thank you for the insight!
David Alayachew

On Thu, Nov 2, 2023 at 5:33 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi David
> On 01/11/2023 21:23, David Alayachew wrote:
>
> 1. In the name of simplifying things for beginners, what is the reason why
> the main method is specifically called "main"? Would not "run" or something
> similar be better? The word "main" implies to me that it is the "main"
> method (out of all of the others). But that right there means I must be
> aware of the concept of there being multiple methods. But again, that's
> forcing the beginner to think about concepts that they don't yet need to.
> Most students' first programs will be solely contained in a single method.
>
> I believe calling it any name other than "main" would compromise one of
> the main goals of this JEP, which is stated nicely in the "Growing a
> program" section (I actually believe this section is, IMHO, the most
> important one in the JEP, and the ones that is driving many of the
> decisions contained in it!):
>
> Even so, all members are interpreted just as they are in an ordinary
> class. To evolve an implicit class into an ordinary class, all we need to
> do is wrap its declaration, excluding import statements, inside an
> explicit class declaration.
>
> Perhaps there's a more intuitive name out there - but regular classes
> would still need a "magic" name to pick what they want to run. And since
> "main" is the magic name that's been used for the last 25 years, our hands
> were a bit forced here...
>
>
>
> 2. Alternatively, could we have the name be irrelevant if it is the only
> method in the class? If we do that, then the concept of the "main" method
> would be really impactful, because, once you introduce the concept of
> multiple methods, students are likely to ask themselves "which method will
> get run first?" In that instance, the concept of a method called main wll
> be extremely intuitive and understandable. I really like this idea. I feel
> like we have an opportunity for a memorable "light bulb" moment in
> student's minds. If they ask themselves which method will be called now
> that there are multiple, the "main" method will make perfect sense the
> first time. It will complicate that launch protocol. For example, do we
> allow parameters? I say, it should follow suit with "main" semantics.
>
> Again, quoting from the above section:
>
> Eliminating the main method altogether may seem like the natural next
> step, but it would work against the goal of gracefully evolving a first
> Java program to a larger one and would impose some non-obvious restrictions
> (see below <https://openjdk.org/jeps/463#Alternatives>). Dropping the void
> modifier would similarly create a distinct Java dialect.
>
> So, it seems natural for an implicit class with one method to behave
> exactly like an implicit class with two methods. Adding special rules for
> an implicit class with one method seems ad-hoc and likely to backfire. E.g.
> you add a method and your program no longer compiles or, if you are unlucky
> and you call the second method "main" now you launch that one instead,
> perhaps unkowingly.
>
> Cheers
> Maurizio
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231102/f5570643/attachment.htm>