With 1.5 I can declare sealed subclasses outside of the parent class. With default sealed subclass ...

# announcements

[Philip Dukhov]

With 1.5 I can declare sealed subclasses outside of the parent class.

With default sealed subclass I can access it easily by Sealed.Subclass, but is there a way to define new subclass in an other file but still be able to have it inside Sealed "namespace"?

class Sealed.NewSubclass: Sealed() is not possible, but maybe there's an alternative?

The reason why I need it is because I wanna generate some of sealed subclasses, and it's very convenient to have all subclasses under single namespace

[ephemient]

no, nested classes cannot be added to from other source files

[ephemient]

can you live with everything in the same package namespace? (that's required anyway...)

[Philip Dukhov]

it would be fine, if I could use package name as I'm using Sealed here: I'm using an architecture where each feature has it's own Msg class, in my code it's inside an object Feature. So I can find all my messages under Feature.Msg.Msg1, and if I just place all messages inside a package I'll have to write this package inside the code, and I can't even import it with an alias: when I have many features in a single file, I import those like import com.package.Feature.Msg as FeatureMsg And can easily get all my msgs under FeatureMsg.Msg
1

[spand]

You can already in 1.4 have sealed subclasses outside of parent class but same file.

I was under the impression that they could reside in different files within the same package in 1.5. Is that not the case? The keep seems to say so

Other classes or interfaces in the same compilation unit and in the package may implement or extend the sealed class

https://github.com/Kotlin/KEEP/blob/master/proposals/sealed-interface-freedom.md

[Philip Dukhov]

That's right. I need to generate part of sealed classes, so they will be in a different file. But I find it not that useful if my sealed subclasses are not under parent class "namespace"

[spand]

The restriction is inherited from java so that will never change.

[spand]

You can still put them in different directories since kotlin does not enforce package/directory symmetry like Java

[Philip Dukhov]

I see 😞 Thanks @spand