Refinements for sealed types
alex.buckley at oracle.com
Tue Aug 20 23:37:00 UTC 2019
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.
More information about the amber-spec-experts