Refinements for sealed types
forax at univ-mlv.fr
Sat Aug 17 11:21:24 UTC 2019
----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Alex Buckley" <alex.buckley at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 15 Août 2019 22:02:35
> Objet: Re: Refinements for sealed types
>> 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.)
one way is to introduce more ceremony to make the implicit permit list more explicit,
by forcing users to write "permits" for all sealed types and have a "permits subtypes" in case you want the compiler to infer the subtypes.
More information about the amber-spec-experts