Motivation for formatting of discriminator with PolymorphicSerializer

[Whathecode]

This is a question, not a bug report.

The discriminator when serializing objects as JSON using the PolymorphicSerializer is stored as the first element in an array:

[
    "this.is.the.descriminator.SomeObject",
    {
       "field1": "Some value",
       "field2": 42
    }
]

This works quite well. However, I noticed that this is not a standard (and it seems like there is no such 'standard'). The discriminator in the built_value package for Dart is stored within the object: { r'$': 'SomeObject, "field1": "Some value", "field2": 42 }

We are trying to deserialize Kotlin serialized JSON objects in Dart, thus this will either require (1) modifying Kotlin's PolymorphicSerializer, (2) handling this in Dart's serializer, or (3) have an intermediate 'transform' step, either in Kotlin or Dart.

To help us make this decision, it would be useful to understand the design rationale behind Kotlin's current format. Is there a benefit of one over the other, or is this simply how it was easiest to implement?

[sandwwraith]

This format was chosen mostly because a) it's much easier to implement b) you don't need to parse JSON in additional data structure to read discriminator from object's field. I can agree that such format is less popular than $class field in object, but we didn't invent it: e.g. Jackson has built-in support for it.

[neworld]

Maybe it is not a big deal, but the current format consumes less space compared to $class.

[pdvrieze]

As a concrete example for why you want format specific work is the XML case. You want to use tag names to distinguish the types. Especially for externally defined formats those names should not be the class names (let alone fully qualified). This comes the point that the API needs a way to enumerate all serializers that are (indirect) child classes of the polymorphic type (parent could be abstract or even an interface).

[sandwwraith]

Starting with 0.11.0, is possible to choose in JsonConfiguration between array-like format and 'embedding' format with specifying key for class name.