Refinements for sealed types

[Alex Buckley]

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