<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:276656784.29954930.1666201819779.JavaMail.zimbra@u-pem.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size:
12pt; color: #000000">
<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;"><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 data-mce-bogus="1">
</div>
<div>- only allowing one compilation unit if there is an
unnamed class.<br data-mce-bogus="1">
</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. <br>
<br>
<blockquote type="cite" cite="mid:276656784.29954930.1666201819779.JavaMail.zimbra@u-pem.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size:
12pt; color: #000000">
<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;"><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 data-mce-bogus="1">
</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. It also
restricts the programming model in ways that rule out pedagogically
useful intermediate refactorings, even if they are not a stable
endpoint. <br>
</body>
</html>