Sealed types
Brian Goetz
brian.goetz at oracle.com
Fri Nov 30 16:16:51 UTC 2018
> Is the intention to allow this:
>
> module M;
> package x.y.z;
> __Sealed interface I { }
> class A implements I {}
> __Unsealed interface B extends I {}
>
> Then, in another compilation unit:
>
> module N;
> package a.b.c;
> class C implements B {}
Yes, unsealing removes all subclassing restrictions.
> ... and then:
>
> module O;
> package d.e.f;
> I x = new C();
> switch (x) {
> case A: ...
> case B: ...
> }
>
> The switch should be considered exhaustive, because both A and B are
> direct children of the sealed interface I.
Yes.
> However, it's possible for
> me to add extra subtypes to B because B isn't sealed, and I still get
> exhaustiveness without mentioning C explicitly.
Correct. A|B is exhaustive over I; if you know about C, you can also
say A|C|B, and its still exhaustive.
> I would expect the following *not* to be exhaustive:
>
> module O;
> package d.e.f;
> I x = new C();
> switch (x) {
> case A: ...
> case C: ...
> }
Correct, not exhaustive. (Allowed by statement switch but not
expression switch.)
> I've mentioned modules and packages explicitly above because it's not
> clear to me if explicitly unsealed interfaces are permitted to have
> implementations in different packages or modules without also losing
> exhaustiveness.
Yes. As mentioned before, I expect unsealing a _class_ to be more
common than unsealing an _interface_, because classes have more tools
with which to defend against rogue subtypes.
More information about the amber-spec-experts
mailing list