[External] : Re: JEP draft: Implicit Classes and Enhanced Main Methods (Preview)

[Archie Cobbs]

On Wed, Feb 15, 2023 at 11:16 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
> The implicit class idea scares me a bit. One issue is that it could turn
> invalid code into "working" code inadvertently.
>
>
> It’s a compile-time error for an implicit class to be a member of a named
> package. So if a “top-level” method is defined in a compilation unit that’s
> in a named package, that will be an error. Additionally, an implicit class
> must have a main method, and an implicit class cannot be directly
> referenced by name.
>
> Do you think that’s not enough protection?
>

Yes - that helps a lot. I would mainly worry about "production"
environments, where the unnamed package is unlikely to be in use.


>
> Is there a good reason why implicit class support should NOT be restricted
> to JEP 330 mode only?
>
>
> Implicit classes are a language feature, while JEP 330 is a JDK
> implementation detail. Restricting implicit classes to source-code
> launching would introduce both a beginners’ dialect and a beginners’
> toolchain, violating two of the JEPs stated anti-goals. The reason they are
> anti-goals is because they run counter to the goal of gradually growing the
> program (they would require switching dialect once you want a proper
> build). The proposed way is both orthogonal, and so easier to specify, and
> supports the goal of gradual growth.
>

Makes sense - thanks for clarifying.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20230215/7b917251/attachment-0001.htm>