What’s the rationale behind not allowing sealed cl...

# language-proposals

[pablisco]

What’s the rationale behind not allowing sealed classes on multiple files?
One use case would be for Android’s RecyclerView and its Viewholder. If there are a significant number of cases it may get a bit too long to keep them all on the same file but on the other hand sealed classes are ideal for this kind of type where the number of implementations is known at compile time.

[bogdoll]

How would you be sure to have found all classes? Having them in one file it is ensured that only those classes are the full extend of implementation and such an exhaustive switch can be guaranteed.

[alexsullivan114]

Couldn't you just search the entire project for all subtypes? I don't understand why the compiler would care that they're in one file.

That being said, having multiple sealed classes in multiple files would 1. make conceptualizing ADTs waaaaaaaaaaay harder since you have to look in any number of places and 2. probably make compilation much slower? Not sure about that point but I imagine having to look through the entire source code of the project would take a lot more time.

[pablisco]

Now I think of it, it may be tricky to block other JVM languages from extending the base type 🤔
I wouldn't recommend it for simple ADTs bit there are certain use cases that could benefit from the split.
That said, in many cases we can be reduced in size by extracting behaviour with ext funs and the like. I was just wondering about any technical or design limitations, that's all 😁

[elizarov]

https://youtrack.jetbrains.com/issue/KT-18370