kotlinx.serialization icon indicating copy to clipboard operation
kotlinx.serialization copied to clipboard

Reduce boilerplate class count

Open develar opened this issue 3 years ago • 3 comments

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?

develar avatar Jan 09 '22 08:01 develar

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

qwwdfsad avatar Jan 10 '22 08:01 qwwdfsad

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...

develar avatar Jan 10 '22 08:01 develar

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.

qwwdfsad avatar Jan 10 '22 09:01 qwwdfsad