Refinements for sealed types
Vicente Romero
vicente.romero at oracle.com
Thu Aug 15 20:29:13 UTC 2019
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
More information about the amber-spec-experts
mailing list