Fields name policy converters

[gildor]

A very common case of serialization is when API/JSON naming policy conflicts with your code naming, for example, snake case quite popular naming style for JSON fields, but for Kotlin it's camel case. Also, format naming style can be incompatible with JVM (for example field names with dashes).
Gson provides feature to solve that: https://google.github.io/gson/apidocs/com/google/gson/FieldNamingPolicy.html (implementation of FieldNamingStrategy)

In general, it's questionable feature, Moshi doesn't provide it and suggests to use the same case for your model classes.

But it can be a big blocker if you want to migrate to kotlinx.serialization, because you have 3 choices:

1. Use @SerialName for each field. Tedious and error-prone and requires a lot of refactoring
2. Rename all your data models to match API name convention. Tedious, requires even more refactoring, violates Kotlin code style guides and backward incompatible.
3. Write own implementation of JSON (or any other format) that provides such feature, looks like a reasonable solution, but now you have one more copy JSON implementation in your project (because JSON implementation now a part of kotlinx.serialization) with different name, but the same API

Possible solutions:

1. Add naming policy feature to JSON implementation. Some drawbacks: doesn't work for other formats, debatable nature of this feature, required not for all use cases.
2. Provide universal API that allows defining name converters. A user can provide own implementation, so not necessary to include it to core fo kotlinx.serialization, works for all formats without additional effort. By default just uses field names as is, so current behavior.
   Possible problems: If you use more than one serialization format, different formats probably require different strategies, so we still should integrate naming policy to format implementation. Also, you sometimes want to use different naming policy for particular requests (from different API), so looks like Serialization format still should provide API to register and use naming policies.

[BoxResin]

This feature is really needed!

[raderio]

@Serializable
data class Data(val a: Int, @Optional val b: String = "42")

What about adding new class JsonSerializationStrategy?

This class can be something like

class JsonSerializationStrategy<T>(
    val serializer: SerializationStrategy<T>, 
    val config: JsonSerializationConfig) : SerializationStrategy(serializer)

Json.stringify will only accept JsonSerializationStrategy.

So, we can set "Fields name policy" in that config class.

Or adding new paramter in Json class.

Why to prefer 1 case: JsonSerializationStrategy can be cached/reused.

[rscottcarson]

Has there been any movement on this feature?

[JakeWharton]

As a Gson maintainer which was used as justification for this feature, we regret field naming policies and do not recommend their use. Moshi, the Gson successor, does not include field naming policies because we view it as a mistake.

[raderio]

Jackson library also has field naming policies.

[pdvrieze]

I would like to propose a 3rd "solution" that is to use an intercepting encoders/decoders. Basically this encoder/decoder would delegate to the actual encoder, but use a delegating SerialDescriptor implementation that does the renaming when/where needed. Note that the generated code cannot know whether a name was provided automatically or manually (using @SerialName).. perhaps something to add a flag for.

Having said that. Related to the GSON issue I would say that there is a reason to not do this a your serialization can be used for two reasons:

• temporary serialization to an opaque format (for deserialization only). In this case names don't really matter, so why bother with having names that are not identical to the Kotlin fields
• permanent serialization to a transparent (defined) format. In this case there is a case for applying @SerialName even in the case that the names are equal, because type member renames should not lead to serial format changes (that would be incompatible).

Intercepting encoders/decoders could be useful for other cases as well (I saw a bug about encrypted data). Perhaps it would be worthwhile to provide a base class for these, but it is also an issue that would be better implemented outside the main runtime library.

[Lewik]

+1 for the global setting and annotation per class

[dragneelfps]

Any plans for this?

[dragneelfps]

We regret field naming policies and do not recommend their use.

@JakeWharton what was the reasoning behind this? I am not sure how would you have any problems if this is used as an optional feature. My guess would be performance concerns?