Refinements for sealed types

[Vicente Romero]

On 8/15/19 4:02 PM, Brian Goetz wrote:
>
>
>> So, A is implicitly sealed, but (IIRC) its lack of `permits` means 
>> that any class which is in the same compilation unit as A and which 
>> says `... extends A` is a permitted subtype.
>
> Currently, yes.
>
>> And, you are saying that it's not reasonable for A's author to have 
>> to oversee the whole compilation unit all the time, just in case some 
>> permitted subtype is lurking around with a `non-sealed` modifier that 
>> lets the X hierarchy be polluted yet further.
> It's more about reading than writing.  Having both the sealed-ness be 
> implicit, and the permits list be implicit, puts a lot of strain on 
> the _reader_.  (Yes, Javadoc will spell it out, but source readers may 
> not.)
>
>>
>>> So, let me propose a simplification:
>>>
>>>   - A concrete subtype A of a sealed type X, which has no permits 
>>> clause, no known subtypes, and is not marked non-sealed, is 
>>> implicitly sealed (with an empty permits clause).
>>
>> Sounds good -- and where "implicitly sealed (with an empty permits 
>> clause)" === "implicitly final", right?
>
> implicitly effectively final, at least.  Whether it is _actually_ 
> ACC_FINAL is a separate matter.
>
well right now all sealed types have the ACC_FINAL set, so would 
implicit sealed classes I think