Paving the on-ramp

[Brian Goetz]

>
>     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. 
>
>
> We can cheaply disallow access by
> - only allowing one compilation unit if there is an unnamed class.
> - mark the generated class as synthetic (see JVMS 4.7.8) so it does 
> not work with separate compilation.

Yes, but this has several disadvantages.

  - More complicated translation schemes mean more speed bumps merging 
onto the highway;
  - It is a more limited programming model, users can't even use records 
unless they are local.

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20221019/3c404c88/attachment.htm>