<div dir="ltr"><div><div>Again, big fan of getting to a streamlined main() source file.</div><div><br></div><div>A major design goal of yours seems clear: to get there without rendering Java source files explicitly bimorphic ("class" source files all look like this, "main" source files all look like that). Instead you have a set of independent features that can compose to get you there in a "smooth ramp". The design looks heavily influenced by that goal.</div><div><br></div><div>And it sounds virtuous. But... is it? Really?</div><div><br></div><div>Take a language that has this pretty streamlined already (I'll use the one I know):</div><div><br></div><div>```</div><div>fun main() {</div><div> ...</div><div>}</div><div>```<br></div><div><br></div><div>As my program grows and gets more complex, I will make changes like</div><div><br></div><div>* use more other libraries</div><div>* add args to main()</div><div>* add helper methods</div><div>* add constants</div><div>* create new classes and use them from here<br></div><div><br></div><div>But: when and why would I be motivated to change *this* code *itself* to "become" a class, become instantiable, acquire instance state, etc. etc.? I don't imagine ever having that urge. main() is just main()! It's just a way in. Isn't it literally just a way to (a) transfer control back and forth and (b) hand me args?</div><div><br></div><div>If I need those other qualities, then I create a class to get them, maybe even right below main(), and I use it. I'm already going to be regularly needing to do that anyway just as my code grows.</div><div><br></div><div><br></div><div>A quick clarification:</div><div><br></div><div dir="ltr">On Wed, Sep 28, 2022 at 12:49 PM Kevin Bourrillion <<a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a>> wrote:<br></div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><font size="4"><font face="monospace">Because excessive use of `static` is considered a code smell, many<br>educators encourage the pattern of "all the static `main` method does is<br>instantiate an instance and call an instance `main` method" anyway.</font></font></div></blockquote><div><br></div><div>Heavy groan. In my opinion, some ideas are too misguided to take seriously.</div><div><br></div><div>The value in that practice is if instance `main` accepts parameters like `PrintStream` and `Console`, and static main passes in `System.out` and `System.console()`. That makes all your actual program logic unit-testable. Great! This actually strikes directly at the heart of what the entire problem with `static` is! But this isn't the case you're addressing.</div></div></div></blockquote><div><br></div><div><br></div><div>Note I was only reacting to "static bad!" here. I would be happy if *that* argument were dropped, but you do still have another valid argument: that `static` is another backward default, and the viral burden of putting it not just on main() but every helper method you factor out is pure nuisance. (I'd suggest mentioning the viral nature of this particular burden higher/more prominently in the doc, as it's currently out of place under the "unnamed classes" section.)</div><div><br></div><div>(That doesn't mean "so let's do it"; I still hope to see that benefit carefully measured against the drawbacks. Btw, *some* of those drawbacks might be eased by disallowing an explicit constructor... and jeez, please disallow type parameters too... I'm leaving the exact meaning of "disallow" undefined here.)</div><div><br></div><div><br></div><div>To resume with the original text...</div><div><br></div></div></div><div><br></div><div>On Wed, Sep 28, 2022 at 10:57 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:<br></div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><font size="4"><font face="monospace">## Unnamed classes<br>
<br>
In a simple program, the `class` declaration often doesn't help
either, because<br>
other classes (if there are any) are not going to reference it
by name, and we<br>
don't extend a superclass or implement any interfaces.</font></font></div></blockquote><div><br></div><div><br></div><div>How do I tell `java` which class file to load and call main() on? Class name based on file name, I guess?</div><div><br></div><div>Tiny side benefit of dropping all the `static`s: then if you also use an unnamed class you can still make method references to your own helper methods.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><font size="4"><font face="monospace">If we
say an "unnamed<br>
class" consists of member declarations without a class header,
then our Hello<br>
World program becomes:<br>
<br>
```<br>
void main() { <br>
System.out.println("Hello World");<br>
}<br>
```<br></font></font></div></blockquote><div><br></div><div><br></div><div>One or more class annotations could appear below package/imports?<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><font size="4"><font face="monospace">
Such source files can still have fields, methods, and even
nested classes, </font></font></div></blockquote><div><br></div><div><br></div><div>Do those get compiled to real nested classes, nested inside an unnamed class? So if I edit a "regular" `Foo.java` file, go down below the last `}` and add a `main` function there, does that cause the whole `Foo` class above to be reinterpreted as "nested inside an unnamed class" instead of top-level?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span style="font-family:monospace;font-size:large">Students need</span><br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><font size="4"><font face="monospace">
not confront the confusing distinction between instance and
static methods yet;<br>
indeed, if not forced to confront static members on day 1, it
might be a while<br>
before they do have to learn this distinction.</font></font></div></blockquote><div><br></div><div><br></div><div>Well, they'll confront it from the calling side, `str.length()` looks quite different from unqualified calls and classname-qualified calls. They'd ideally get a chance to understand that first before making their own classes.</div><div><br></div><div>This is my notion of a natural progression:</div><div><br></div><div>1. Write procedural code: calling static methods, using existing data types, soon calling their instance methods</div><div>2. Proceed to creating your own types (from simple data types onward) and using them too</div><div>3. One day learn that your main() function is actually a method of an instantiable type too... at pub trivia night, then promptly forget it</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><font size="4"><font face="monospace">The fact that
there is a<br>
receiver lurking in the background will come in handy later,<br></font></font></div></blockquote><div><br></div><div><br></div><div>(My claim up above is "I don't think it will.")</div><div><br></div></div><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div></div>