JEP-360 Sealed types and non-accessible subtypes

[Remi Forax]

----- Mail original -----
> De: "Michał Kłeczek" <michal at kleczek.org>
> À: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Dimanche 1 Décembre 2019 19:10:21
> Objet: Re: JEP-360 Sealed types and non-accessible subtypes

> I have just realized permits clause is in fact optional. Optionality is
> though only a syntactic sugar to save some keystrokes.
> I think it might be useful to change its semantics to mean any type in
> the same module and not just the compilation unit.

i've hard time to understand what your are suggesting:
- is it, if a sealed interface need to be compile then all files in the module need to be recompile ?
- or is it if a class inside a module is changed, because we don't know if there is a sealed interface in it or not, we need to recompile the whole module ?

In both cases, is it not equivalent to say that you can not compile a module incrementally anymore ?

> 
> Thanks,
> Michal

regards,
Rémi Forax

> 
> On 01/12/2019 12:36:54, "Kłeczek, Michał" <michal at kleczek.org> wrote:
> 
>>Hello,
>>
>>I would like to ask about JEP-360 proposal in the context of "module
>>implementation only types"
>>(ie. public types that can only be extended/implemented by types in the
>>same module).
>>
>>Right now there is only limited support for this: one can define a
>>public abstract class with non-public constructor.
>>
>>Sealed types seem to provide such a feature but IMHO there is a couple
>>of concerns:
>>
>>The syntax requires to explicitly list all permitted subtypes.
>>It could be possible to make permits clause optional. Omitting it would
>>mean "all subtypes in the same module".
>>I admit such syntax is just a nice to have as explicitly listing
>>subclasses is not such a big deal
>>when all types must be in the same module anyway.
>>
>>What is interesting though is the interaction of permitted types
>>declaration and exhaustiveness check:
>>how should it work in case when a public sealed type permits a
>>non-public/non-exported type?
>>
>>Introduction of exhaustiveness check also means adding a new permitted
>>subtype is an incompatible change
>>- similar to adding a value to existing enum.
>>This makes it somewhat less useful for the module implementation only
>>types use case.
>>The solution might be to have sealed types without explicit permits
>>clause (see above) and
>>such types could not be used for exhaustiveness checks.
>>
>>Kind regards,
> >Michal