while working on an Android project I noticed that it's not possible to define a sealed class hierar...

# getting-started

[Francesc]

while working on an Android project I noticed that it's not possible to define a sealed class hierarchy across multiple modules (my idea was to define a sealed interface in 1 module and have child classes in other modules)- what is the limiting factor for this? Is it something in the JVM?

[Kirill Grouchnikov]

All direct subclasses of a sealed class are known at compile time. *No other subclasses may appear outside a module within which the sealed class is defined*.

[Francesc]

right, but that is the technical limitation? that the compiler can't determine how many there are if they are in multiple modules?

[Kirill Grouchnikov]

Not even clear how an exhaustive when would work when the leaves are spread across multiple modules

[Kirill Grouchnikov]

See https://kotlinlang.org/docs/sealed-classes.html#sealed-classes-and-when-expression where this is presented as a key benefit

[Francesc]

I understand the usage of when, and that's the reason I was building this hierarchy, I was just not aware it was not possible to spread it across modules so I was trying to understand the reason behind that

[ephemient]

the set of modules is not known to the compiler

[Kirill Grouchnikov]

Putting aside the possible technical considerations, how would when work when the leaves are spread across multiple modules? How would the compiler be able to compile the module with that when? How would you even import all the leaves scattered across the modules, unless every module depends on everything else.

[ephemient]

Java has similar limitations on its sealed classes: https://docs.oracle.com/en/java/javase/15/language/sealed-classes-and-interfaces.html

[Francesc]

the set of modules is not known to the compiler

thanks, that's the kind of concise answer I was looking for

[ephemient]

that's just the first technical hurdle, but Kirill brings up good design reasons for it as well

[Kristian Nedrevold]

Even if you could, you probably should not. Sharing implementation details between your modules will just bring you pain

[Francesc]

thanks, I was not planning on sharing implementation details, just have a common base interface for all classes, with each having its own implementation, but that's a separate discussion from the technical reasons for why it's not supported

[Kirill Grouchnikov]

The example in the Java documentation on Shape classes isn’t the strongest. There’s a good argument against using a sealed shape hierarchy in a geometry library, as that would prevent 3rd parties to implement their own shapes.

But then there’s also a good argument on what could be done with that “loosely sealed” hierarchy when you can’t enumerate all the leaves in a when

[Kirill Grouchnikov]

A common base interface wouldn’t be sealed

[ephemient]

simple OO examples are often pretty bad :(

[Francesc]

sealed interface ?

[Kirill Grouchnikov]

If you want to prevent “unauthorized” extending classes, you wouldn’t use sealed. Probably some sort of combination of builders and private / protected constructors.

[ephemient]

or using @RequiresOptIn to emulate "`internal` to a set of modules" but yeah

[José González D'Amico]

I know it's not ideal, but maybe repeating the base interface in each module works?

[Francesc]

I"m not sure how that would work, the child classes have to be on the same package, so you'd have a duplicated class declaration (the interface)

[José González D'Amico]

yes, I mean an on purpose duplication. Not ideal, but maybe you can live with that

[José González D'Amico]

oh wait, it doesn't make any sense (I need a vacation)

[Kirill Grouchnikov]

how would that even compile and package into a single binary