I do, because the other way to get a class into the same compilation unit, aux
classes, have some limitations. So we’re encouraging the pattern of nesting.
But … I am not sure we want to push it all the way. Consider a type like:
sealed interface Fruit {
interface RedFruit extends Node { }
interface BlueFruit extends Node { }
class Strawberry implements RedFruit { }
class Raspberry implements RedFruit { }
class Blueberry implements BlueFruit { }
}
Do we want to force Blueberry to be Fruit.BlueFruit.Blueberry (or at least,
twist the user’s arm into it by offering less ceremony?) I think that would be
lame — and worse than lame if the intermediate interfaces (RedFruit, BlueFruit)
were not public. Then we’d be nesting the public types in the nonpublic ones,
and they’d be inaccessible.
> You often show the concrete classes as members of a sealed interface.
> Interface members are already implicitly public and static; is this a
> precedent to build on for a sealed interface? That is, have the nested
> concrete classes be implicitly final, and have the interface's implicit
> `permits` list care about only nested concrete classes. Top level concrete
> classes in the same compilation unit would be handed like concrete classes in
> other compilation units: nothing different than today.
>
> Layering sealing on top of nesting has the attraction that it avoids putting
> multiple public concrete classes in a single compilation unit. It's right
> that the concrete leaves are public, but javac dislikes compilation units
> with multiple public types.
>
> Alex
