one more other question: how should classes define...

# ksp

[Zac Sweers]

one more other question: how should classes defined via metadata (but not class hierarchy) work?

Example case: I have a processor that generates an adapter for a sealed class and references all of its sealed subtypes. I've treated it as basically "isolating" up until now because we could get all the information from the original sealed class

[Ting-Yuan Huang]

In general, if you get elements through metadata rather than KSP's API, you'll have to tell KSP by adding the corresponding sources. However, the only way to get a KSNode is through KSP's API. Therefore you either get them by Resolver (and need to associate them with relevant outputs), or through other KSNode.

If what you get is, for example, a KClass, then it is completely out of KSP's control. You'll have to associate the files that contains all the information you used manually.

In the case of sealed class, if you get the sealed class via KSP, you don't have to do anything on the subtypes, because sealed subtype must be defined in the same file with the supertype.

[Zac Sweers]

for now yes, but fyi that that limitation is going away with the introduction of sealed interfaces

[Ting-Yuan Huang]

In that case I think we either need to add something like getAssociatedOutputs(source: KSFile) so that this can be implemented on top of rest of the API, or simply provide getSealedSubclasses, which would be similar to getSymbolsWithAnnotation

[Zac Sweers]

getSealedSubclasses() would be super useful 👍. Right now I just do it like this: https://github.com/ZacSweers/MoshiX/blob/main/moshi-sealed/codegen-ksp/src/main/ko[…]csweers/moshix/sealed/codegen/ksp/MoshiSealedSymbolProcessor.kt

[Ting-Yuan Huang]

Filed a tracking issue: https://github.com/google/ksp/issues/218