Lifting the restriction on the number of public classes per file

Remi Forax forax at
Tue Nov 27 07:40:22 UTC 2018

> De: "John Rose" <john.r.rose at>
> À: "Kevin Bourrillion" <kevinb at>
> Cc: "amber-spec-experts" <amber-spec-experts at>
> 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:kevinb at |
> kevinb at ] > 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
> a little more carefully to determine if 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list