RFR: JEP 360: Sealed Types (Preview)

[Alex Buckley]

(Was meant to be private, but I didn't spot that compiler-dev was still 
cc'd after I removed amber-dev. Doesn't matter. Vicente, please do 
clarify whether you're still working on the text. I would like to see 
the structure of *Controlling implementations* and *Algebraic sum types* 
recorded in the Motivation, perhaps under more approachable headings. 
For the latter, I thought the observations by Jonas Konrad and Swaranga 
Sarma were on the money -- some interfaces represent "APIs" (implement, 
don't match) and some represent "data types" (match, don't implement).)

On 4/14/2020 2:25 PM, Alex Buckley wrote:
> // 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