On 8/20/2019 3:45 PM, Brian Goetz wrote:
This seems reasonable too, because most concrete classes in such hierarchies _will be_ leaves. In this world, though, it feels a little inconsistent to only do this when the subclass and the sealed type are in the same compilation unit; we could extend this to all concrete subclasses of sealed types (implicitly final, unless they say sealed or non-sealed). This is consistent, but feels a little more action-at-a-distance-y. So, its pick your poison.
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
