Looking at <https://github.com/android/kotlin/pull...
# ksp
z
Looking at https://github.com/android/kotlin/pull/98, I’m not sure it quite solves the original issue as nicely as it could. Namely, one has to get the package name from the declaration and then remove it from the fully qualified name. It’s a little awkward not to have a nested naming API. I think it’d still be worth adding to the
KSName
API as well, then it would be easy for us to write something like
fun KSName.toClassName(): ClassName
in KotlinPoet or similar
j
The slash based behavior is the behavior of JVM runtime name, therefore since we are targeting more than just jvm we want make it less platform dependent. Actually by Java language spec it should also be dot separated for qualified names. See https://github.com/android/kotlin/issues/23 for more context.
It is true that it is making use cases like KotlinPoet hard to implement toClassName functionality though. What do you think of maybe adding some alternative APIs based on declarations for working with nested classes?
z
That could work, but I'm curious if just adding packageName to KSName would be enough to sort of covers all these cases
j
I can think of you still need additional efforts to get the containing classes’ names for nested/inner classes.
z
yeah it’s just inconvenient to have to stitch this together in every project
when it could just be added to KSName or expose a deterministic name like Kotlin uses in metadata
j
How about providing a jvm name API for declaration? Note that if you feed the name obtained from this API to KSP, it might not work.
u
Just wanted to chime in to say that we chose the
package/Outer.Inner
format in the Kotlin metadata (and subsequently exposed in the kotlinx-metadata library) specifically because it’s a single string which uniquely identifies a class and all its containing classes and package. I don’t know whether it’s justified to have the same format for names in KSP, but it has nothing to do with JVM, the same is also true for metadata on JS and Native. We could have chosen any other set of delimiter characters, these just seemed the most obvious. In fact, names in the JVM bytecode are mostly
package/Outer$Inner
which is not unique enough because classes are allowed to have
$
in the names.
1
z
yeah I’d prefer to just match what metadata does for the reasons Alex mentions. Makes it easy for tools to reuse logic and better than jvm name since
$
isn’t reliable enough
j
Regarding this, we were in a discussion of reworking KSName implementation. Currently the plan is to make KSName slash based, and while being printed, it can be printed in either way (dot based, slash based), but because of the slash based nature, when creating new names from string, 2 inputs are needed (package, enclosing declarations). Also only partial names (e.g. package name) will be returned as string, KSNam will only be returned when a FQN is requested.