tschuchort
01/25/2019, 7:18 PMCasey Brooks
01/25/2019, 7:40 PMval
in the class body (so it can’t be changed in a constructor), and do the when
checks on that node type instead of the node class itselftschuchort
01/25/2019, 8:26 PMkarelpeeters
01/27/2019, 12:38 PMtschuchort
01/27/2019, 1:32 PM@JvmMultifileClass
as well, but I'm fairly confident it's bullshit. If you look at the generated bytecode, @JvmMultifileClass
doesn't work like that, it only affects top-level constructs like functions, properties and type aliases that normally can't be top-level in Java. Classes are always independent and know nothing about their Kotlin file.
It's not like I can't achieve the same with abstract leaf-classes in my sealed hierarchy and lots of Impl
classes, it just sucks majorly.In fact I was doing an AST toohopefully not the same thing I'm working on 😏
karelpeeters
01/27/2019, 1:55 PMtschuchort
01/27/2019, 1:56 PMkarelpeeters
01/27/2019, 2:00 PMtschuchort
01/27/2019, 2:02 PMkarelpeeters
01/27/2019, 2:03 PMtschuchort
01/27/2019, 2:07 PM@MultifileSealed(suffix = "Impl)
internal class MySealedLeafImpl() : MySealedBaseImpl() {
fun foo() {}
}
and the processor generates another class:
class MySealedLeaf : MySealedBase() {
private val impl = MySealedLeafImpl()
fun foo() = impl.foo()
}
You'd have two classes with similar names for every class you want to have. But that's a small price to pay for practically free multifile sealed classes and you could even try to isolate the impl classes by making them internal in a different modulekarelpeeters
01/27/2019, 2:08 PMtschuchort
01/27/2019, 2:09 PM