Paving the on-ramp

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, October 19, 2022 8:54:44 PM
> Subject: Re: Paving the on-ramp

>>> 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.
Users can still use record members too. But yes, everything has to be in the same compilation unit is perhaps too restrictive. 

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. 

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

> It also restricts the programming model in ways that rule out pedagogically
> useful intermediate refactorings, even if they are not a stable endpoint.

What is the aim of those refactorings ? 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20221019/3dcf3a08/attachment.htm>