Thank you, Arturo, for your response.

I completely agree with you. My example is not a guide to action, it is just interesting note, additional to your article. But in the same time I want to make things clear. Main difference in my hacky java approach and your kotlin approach is data structure rules.

So in my java case we have some agreements, that, for example, FILE_FILM_COUNT must work with dataInt and FILE_METALLICA_NEM with dataStr. But in you approach these agreements are built into the language, so if we will broke them, then we will have compile time error, unlike java hacky approach, which will have runtime error.

In other words, sealed classes approach more stable and error prone, which is, I think, very good. :)