<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Sent: </b>Wednesday, October 19, 2022 8:54:44 PM<br><b>Subject: </b>Re: Paving the on-ramp<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br>
<blockquote cite="mid:276656784.29954930.1666201819779.JavaMail.zimbra@u-pem.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size:
12pt; color: #000000">
<div>
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4"><font face="monospace"><br>
We could, of course, prevent class access from outside
the class too, effectively making such classes visible
only to the launcher. But this would come at no small
cost to prevent such accesses, and for limited benefit. </font></font></blockquote>
<div><br>
</div>
<div>We can cheaply disallow access by<br>
</div>
<div>- only allowing one compilation unit if there is an
unnamed class.<br>
</div>
<div>- mark the generated class as synthetic (see JVMS 4.7.8)
so it does not work with separate compilation.</div>
</div>
</div>
</blockquote>
<br>
Yes, but this has several disadvantages. <br>
<br>
- More complicated translation schemes mean more speed bumps
merging onto the highway;<br>
- It is a more limited programming model, users can't even use
records unless they are local.</blockquote><div><br></div><div>Users can still use record members too. But yes, everything has to be in the same compilation unit is perhaps too restrictive.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Perhaps only marking the unnamed class as synthetic is a better tradeoff, it means you can compile it with other files but separate compilation is not supported. <br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"> <br>
<br>
<blockquote cite="mid:276656784.29954930.1666201819779.JavaMail.zimbra@u-pem.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size:
12pt; color: #000000">
<div>
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4"><font face="monospace"> The status-quo proposal
currently says: the name of the class is not visible
from within the class, you can't have constructors or
instance initializers, you get an implicit no-arg
constructor like every other constructor-less class. If
you want a more complex construction protocol, or
supertypes, or class declaration annotations, or to live
in a package, declare a class. This still seems pretty
OK. </font></font></blockquote>
<div><br>
</div>
<div>I still think that allowing fields inside an unamed class
is a mistake (if we can avoid to talk about null at the
beginning, it's a win).<br>
</div>
</div>
</div>
</blockquote>
<br>
I understand why this is appealing to you, but again, it smacks of
trying to engineer a "beginner-safe programming model subset", which
I think is a fool's game here. The goal is to match the ceremony
overhead to what the user actually uses. Requiring a class
declaration in order to declare a superclass makes sense -- because
this is where a class declaration adds value -- but "no fields"
seems more of a gratuitous, paternalistic restriction.</blockquote><div><br></div><div>It's about cognitive load, we are asking our users to internalize that code should be written only inside methods, but you are proposing that users will be able to write "int x;" outside a method.</div><div>Most beginner to Java have been already exposed to either Python or JavaScript, so not being free to write code where they want is a main issue when starting.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"> It also
restricts the programming model in ways that rule out pedagogically
useful intermediate refactorings, even if they are not a stable
endpoint. <br></blockquote><div><br></div><div>What is the aim of those refactorings ?<br></div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></div></body></html>