kotlinx.serialization
kotlinx.serialization copied to clipboard
Reduce boilerplate class count
What is your use-case and why do you need this feature?
Support for kotlinx serialization for persistence state components in the IntelliJ IDEA platform.
One of the concerns of using kotlinx serialization — increased bytecode size.
Say, I see that the following class is generated:
public static final class Companion {
private Companion() {}
@NotNull
public final KSerializer<PluginFeatureService.State> serializer() {
return (KSerializer<PluginFeatureService.State>)PluginFeatureService.State.$serializer.INSTANCE;
}
}
What for do we need an additional separate class? Why this simple method cannot be simply a static method of a corresponding serializable class?
Why this simple method cannot be simply a static method of a corresponding serializable class?
Because Kotlin does not have the notion of static methods. Once it's here, we may reconsider the decision. The problem is not only the notion of the language surface but implementation as well, AFAIR we couldn't generate such method using plugin API either
Because Kotlin does not have the notion of static methods.
Well, it is internal implementation, if I am not wrong, current experimental API to get serializer for a class, uses kotlin reflection wrapper for that.
AFAIR we couldn't generate such method using plugin API either
Will be great if you will somehow improve that. You can say that it is premature optimization but given the size of IJ Platform and plugins...
Well, it is internal implementation
It is not, it's part of the public API surface. Serializer for any class can be retrieved using this method, e.g.:
@Serializable
class Box(...)
val boxSerializer = Box.serializer() // <- this method *should* be resolved to something and be actually denotable
Such constraint makes the transition to a potential static solution much harder, similar to the @JvmDefault story.
I'm not saying we are not going to do that though, just pointing out it is more delicate than it appears.