<div dir="ltr"><div>Meta-comment: I think you have the right *motivating* use cases (beginners, small/temporary programs), but I expect pretty much *any* main method to want to use this, and I don't see why it shouldn't. That makes those use cases important and worth reasonable attempts at accommodation, regardless of whether we'd even be doing this for their sake alone.</div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 28, 2022 at 6:36 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<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>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<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>
</div>
</blockquote>
<br>
Yes, I sometimes call this "telescoping", because there's a chain of
"x is short for y is short for z". For example, with lambdas:<br>
<br>
x -> e<br>
<br>
is-short-for<br>
<br>
(x) -> e <br>
<br>
is-short-for<br>
<br>
(var x) -> e <br>
<br>
is-short-for<br>
<br>
(int x) -> e // or whatever the arg is<br>
<br>
As a design convention, it enables a mental model where there is
really just one form, with varying things you could leave out.
Early in the Lambda days, we saw articles like "there are N forms of
lambda expressions", and that stuff infuriates me, it is as if
people go out of their way to find more complex mental models than
necessary. </div></blockquote><div><br></div><div><br></div><div>Right, and that design was good inasmuch as there were good use cases for every one of the rungs (and there were).</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>
<blockquote type="cite">
<div dir="ltr">
<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></div></blockquote>
This doesn't seem like such a leap to me. You might start out
hardcoding a file path that will be read. Then you might decide to
let that be passed in (so you add the args parameter to main). Then
you might want to treat the filename to be read as a field so it can
be shared across methods, so you turn it into a constructor
parameter.</div></blockquote><div><br></div><div>So far so good up to that last part. A constructor parameter? I thought you were going to say you just add the field and all your non-static methods read and write it at will. Getting a bit lost in the twists n' folds.</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> One could imagine "introduce X" refactorings to do all
of these. The process of hardcoding to main() parameter to
constructor argument is a natural sedimentation of things finding
their right level. (And even if you don't do all of this, knowing
that its an ordinary class (like an enum or a record) just with a
concise syntax means you don't have to learn new concepts. I don't
want Foo classes and Bar classes.)<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div class="gmail_quote"><br>
<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>
</div>
</div>
</blockquote>
<br>
Indeed, I intend that there are no explicit constructors or instance
initializers here. (There can't be constructors, because the class
is unnamed!) </div></blockquote><div><br></div><div>Hmm, I was under the impression I could drop all my `static`s while keeping the class signature if I wanted? But, if I can and even then explicit constrs and initers are banned, then indeed, at least one of my drawbacks is invalid. I don't think it undercuts my overall case that much.</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>I think I said somewhere "such classes can contain
..." and didn't list constructors, but I should have been more
explicit. <br>
<br>
<blockquote type="cite">
<div dir="ltr"><br>
<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>How do I tell `java` which class file to load and call
main() on? Class name based on file name, I guess?</div>
</div>
</div>
</blockquote>
<br>
Sadly yes. More sad stories coming on this front, Jim can tell. <br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote"><br>
<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>
</div>
</blockquote>
<br>
No package statement (unnamed classes live in the unnamed package),
but imports are OK. </div></blockquote><div><br></div><div>I'm confused; what does any of this have to do with package location? Isn't that orthogonal to everything we're discussing?</div><div><br></div><div>I'm also not sure why we're talking about "unnamed" so much; the condition we're talking about is really "signatureless" or "body-only", which as far as I know could be a purely source-level distinction, producing a completely normal-looking, named class in a classfile. (Wrote that before Guy's message came in, even.)</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> No class annotations. No type variables. No
superclasses.</div></blockquote><div><br></div><div>Okay, in the motivating use cases (beginner/small/temp), yeah, they're awfully unlikely to want class annotations.</div><div><br></div><div>But again, to me every main() method out there is a use case too. And plenty of class annotations are used for purposes that aren't about *classes*, just "this whole range of code here". It feels like they should be allowed, unless you want to talk about `ElementType.COMPILATION_UNIT` ... :-)</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>
<blockquote type="cite">
<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"> Such source
files can still have fields, methods, and even nested
classes, </font></font></div>
</blockquote>
<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>
</div>
</blockquote>
<br>
To be discussed!<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">This is my notion of a natural
progression:
<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>
</div>
</blockquote>
<br>
Right.<br>
<br>
<br>
<br>
</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><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>