<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>