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
