On Wed, Feb 15, 2023 at 11:16 AM Ron Pressler <[email protected]> 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
