Implicit Record Was: JEP draft: Implicit Classes and Enhanced Main Methods (Preview)

forax at forax at
Mon Feb 20 21:38:12 UTC 2023

> From: "Brian Goetz" <brian.goetz at>
> To: "Remi Forax" <forax at>
> Cc: "Ron Pressler" <ron.pressler at>, "Dan Heidinga"
> <heidinga at>, "amber-spec-experts" <amber-spec-experts at>
> Sent: Monday, February 20, 2023 9:33:34 PM
> Subject: Re: Implicit Record Was: JEP draft: Implicit Classes and Enhanced Main
> Methods (Preview)

>> As i said earlier, it does not work because fields and local variables have
>> different semantics,
>> fields are initialized with a default value while local variables need to be
>> initialized before use.
>> So the curtain is just a veil that will be pierced by any students moving
>> declarations around.

> Of course it "works", it just might not work how you would prefer it to.
var greetings = 0; 

does not work, 

void main() { 
int greetings; 

does not work, 

void main() { 
static int greetings; 

does not work, 

void main() { 
int greetings = 0; 
for(;;) { 
int greetings = 0; 

does not work too. 

Scope rules are different, being static is different, initialization rules are different, inference rules are different, even colors in IDEs are different. 

> Prior to learning about fields, the user can perceive local variables (declared
> in a method) and "shared" variables (accessible to all members of the class.)
> They can learn about their characteristics. Then, when they learn about classes
> and fields and accessibility, they can learn that the variables they were
> calling "shared" are really fields. The distinction between locals and fields
> is there from the beginning, though for most use cases, they will not notice
> the difference. When they're ready to learn the fine differences, there's not
> anything to unlearn.

>> From my personal experience, unifying local variable and field leads to more
>> pain than gain, mostly because local

> Who said anything about unification of fields and locals? Where did you get such
> an idea that this is what is being proposed?
You did, by re-using the term "variables" for both local variable and fields. 

> First students will learn about statements. Then they will probably learn about
> local variables. They can be taught that they disappear when the method exits,
> and each invocation of the method gets a fresh copy. Then they can learn about
> multiple methods, and then that there are variables that can be shared across
> methods and retain their values across method invocations, and while their
> declaration syntax is the same (they're both variables, after all), the _place_
> in which they are declared is different (which is what makes them shared), and
> shared variables have slightly different characteristics (though not so
> different they have to learn this immediately). They can learn the
> characteristics of shared variables when it makes sense to teach this. And when
> the curtain is pulled back, they learn all fields have the characteristics of
> these shared variables.
Record components behave as you said, they have slightly different characteristics than local variables and it's hard to not notice the difference syntactically. 

record Hello(String name) { 
void hello() { 
System.out.println("hello " + name); 

void bonjour() { 
System.out.println("bonjour " + name); 

Class fields are far more different than just the lifetime but have a very similar syntax. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list