You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
data class Node(val data: Int, val nodes: List<Node>)
For that, kotlinx.serialization is able to generate a proper serializer (using the coupling between auto-generated serializer and childSerializers loophole), but there is no public API to write it an external (or custom) serial descriptor/serializer for that.
When solving the similar problem for JsonElement serialization, we ended up with the following:
In addition it would be good to make sure that the library (and all formats) work correctly with user provided serial descriptor implementations.
In terms of the general solution, it would be good if the solution could be properly self-referential (rather than having lazily generated copies). This may be mainly the documentation of preferring Type::serializer().serialDescriptor.
Not sure I follow here, could you please elaborate on the idea?
In addition it would be good to make sure that the library (and all formats) work correctly with user provided serial descriptor implementations.
This part, I think, we'll be extensively covered by tests (and the whole approach is more or less battle-tested with JsonElementSerializer).
it would be good if the solution could be properly self-referential (rather than having lazily generated copies)
The caveat here is that all intermediate serializers have to be aware of that.
I.e. the caveat here is that in the following:
// In node serializer class
buildSerialDescriptor {
element<List<Node>>(...)
}
it is s List serializer that has to be aware its type argument serializer should be retrieved lazily, not our machinery. The same goes for any other parametrized serializer
I suspect it works already (due to JsonElementSerializer), but some other cases special case specific serializers (AbstractPolymorphicSerializer). In any case, I would see the self-referential aspect as mainly an optimization, hence the idea of just documenting it. I would say that any attempt at caching/lookups would be hard and certainly not worth it if possible at all.
Consider the following class:
For that,
kotlinx.serialization
is able to generate a proper serializer (using the coupling between auto-generated serializer andchildSerializers
loophole), but there is no public API to write it an external (or custom) serial descriptor/serializer for that.When solving the similar problem for
JsonElement
serialization, we ended up with the following:kotlinx.serialization/formats/json/commonMain/src/kotlinx/serialization/json/JsonElementSerializers.kt
Lines 219 to 235 in 776e3c1
Potentially, we can streamline it, pick a decent name (e.g.:
recursive
,deferred
,nested
) and make it publicThe text was updated successfully, but these errors were encountered: