> De: "John Rose" <john.r.r...@oracle.com> > À: "Kevin Bourrillion" <kev...@google.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Mardi 27 Novembre 2018 03:04:01 > Objet: Re: Lifting the restriction on the number of public classes per file
> On Nov 26, 2018, at 11:43 AM, Kevin Bourrillion < [ mailto:kev...@google.com | > kev...@google.com ] > wrote: >> Multiple top-level classes per file just make code harder to find; what are >> the >> advantages? > I suppose the main advantage (as suggested in the examples) would be > flexibility of naming. With inner classes your names are pkg.NH.{A,B,C…}, > where the outer class NH serves as nest host and also scope. With the > proposal the names could also be pkg.{A,B,C…}, with a common nesthost > (A or NH). > In source code the simple names can be obtained by using an import > which mentions NH: `` import pkg.NH.* ``. So there's no great source-level > advantage to having the top-level names (package members) instead > of the nested names (class members). Maybe there's some advantage > in having reflection avoid mention the "NH$"? > The hardest downside to the proposal is that IDEs and some javac > compilation modes (source-paths) don't know where to look for a file > containing pkg.A, if the classfile pkg/A.class has not yet been generated. > I suppose one answer to that is, "the source path mode doesn't work on > such top-level auxiliary nest membrers". And IDEs have to sniff at NH.java > a little more carefully to determine if NH.java contains extra definitions. > But these issues already exist and have a user model, right? given that you can already have several compilation unit in one file (only marked public), i believe the answer is yes. > On the whole, I don't see a big downside, but neither do I see a killer > use case for pkg.A that isn't covered by pkg.NH.A. The use case for pkg.A instead of pkg.MH.A is refactoring, i.e. refactor an existing hierarchy of top level types to use a sealed interface. > — John Rémi
