On 2018-11-30T11:16:51 -0500
Brian Goetz wrote:
>
> 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.
>
Sounds good, thanks!
Do you have any documentation on
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 t
On 2018-11-27T17:20:54 -0500
Brian Goetz wrote:
> Since we’re already discussing one of the consequences of sealed types,
> let’s put the whole story on the table. These are my current thoughts,
> but there’s room in the design space to wander a bit.
Is the intention to allow this:
module M;
|sealed interface Node { ... } |
In this streamlined form, |Node| may be extended only by its
nestmates. This may be suitable for many situations, but not for
all; in this case, the user may specify an explicit |permits| list:
|sealed interface Node permits FooNode, BarNode
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mardi 27 Novembre 2018 23:20:54
> Objet: Sealed types
> Since we’re already discussing one of the consequences of sealed types, let’s
> put the whole story on the table. These are my current thoughts, but there’s
> room in the design space
