RFR: JEP 360: Sealed Types (Preview)

[Alex Buckley]

// Private

On 4/14/2020 12:51 PM, Paul Sandoz wrote:
> - You still mention Node instead of Shape in some places.

I assume that the JEP is still in editing territory, so I have held off 
making corrections like this. Vicente, is that true? I mean, there are 
still access control scenarios to add to the Motivation, plus Brian's 
two-item response to Ty Young.

> - On the set of restrictions you mention
> 
> "
> It is an error if a class has a sealed direct superclass or 
> superinterface and the class is not an enum type or the class is not 
> explicitly declared sealed, final or non-sealed.
> “
> 
> To be complete I presume you can add records to that restriction.

I assume that Vicente is going to blow up the list of restrictions that 
is merely an incomplete and hard-to-sync copy of JLS content. I 
explained why this was important in other mails: the JEP should explain 
why the language feature works the way it does, because everyone in the 
Java community is going to read the JEP directly or indirectly (you've 
seen those InfoQ articles which are 90% copy-paste from JEPs, right?), 
and the JLS will pick up those designs/policies and turn them into 
formal mechanical rules, which few people need to read.

Alex