----- Original Message -----
> From: "Tagir Valeev" <[email protected]>
> To: "Brian Goetz" <[email protected]>
> Cc: "amber-spec-experts" <[email protected]>
> Sent: Thursday, September 29, 2022 9:07:44 AM
> Subject: Re: Paving the on-ramp

> Hello!
> 
> Very interesting writing, thanks! A couple of notes from me:
> 
>> ## Unnamed classes
>> ...
>> Such source files can still have fields, methods, and even nested classes, so
>> that as a program evolves from a few statements to needing some ancillary 
>> state
>> or helper methods, these can be factored out of the `main` method while still
> 
> I wonder how we tell apart unnamed class syntax and normal class
> syntax. E.g., consider the source file:
> 
> // Hello.java
> public class Hello {
>  // tons of logic
> }
> 
> void main() {
> }
> 
> Will it be considered as a correct Java file, having Hello class as a
> nested class of top-level unnamed class?
> If yes, then, adding a main method after the class declaration, I
> change the class semantics, making it an inner class.
> This looks like action at a distance and may cause confusion. E.g., I
> just wrote a main() method outside of Hello class instead of inside,
> and boom,
> now Hello is not resolvable from other classes, for no apparent reason.

There are several ways to try to tame that issue
- we can restrict unnamed class to only work if it is run by java Hello.java, 
so no Hello.class is generated at compile time, no problem with Hello being 
resolvable.
- we can disallow an unnamed class to contains a nested class with the same 
name as the unnamed class, the error message will still be hard to decipher for 
beginners.
- we can disallow nested class in unnamed class, but that a bummer because 
being able to write records inside an unnamed class is a great combo.

> 
> I assume that the main() method is required for an unnamed class, and
> if there are only other top-level declarations,
> then it should be a compilation error, right ?

I do not think you can because having a file named Foo.java containing only a 
non public class Bar is currently legal in Java.

> 
>> ## Predefined static imports
>> ```
>> void main() {
>>     println("Hello World");
>> }
>> ```
> 
> I wonder how it will play with existing static star imports. We
> already saw problems when updated to Java 9 or Java 14 that
> star-imported class named Module or Record becomes unresolvable. If
> existing code already imports static method named println from
> somewhere, will this code become invalid?

yes, i've asked the same question to Brian.
We need the predefined static imports to be resolved after the classical static 
imports are resolved.

BTW, there is a connection with the templated string spec here, because STR or 
FMT also needs to be predefined static imports.

> 
> With best regards,
> Tagir Valeev.

regards,
Rémi

Reply via email to