Is there anywhere that details the specs for seria...
# serialization
c
Is there anywhere that details the specs for serializer structures? stuff like "polymorphic serializer's element 0 is expected to be the type name, and element 1 is the value. elements of value's descriptor are sealed subclasses, if any"
d
Polymorphism is determined by the format. JSON for example doesn't follow "array polymorphism" by default, which is what you've described.
There's a serializer guide in the repo.
c
Polymorphism is determined by the format.
I am talking about the descriptors in KSerializers that formats receive, those are not format-specific
d
Sure. Those you'll find in the source code, since it's largely an implementation detail.
c
yeah, that's what I was wondering about, cause clearly there's some expectation that the format will always be the same, even with hand-written serializers' descriptors, for things like JSON to know how to encode polymorphism differently
would be great if it was actually outlined somewhere but doesn't look like it
d
cause clearly there's some expectation that the format will always be the same
What do you mean? I don't currently sense this expectation.
The Json format simply checks if the default
PolymorphicSerializer
class is used, then does it's custom polymorphism formatting. If the user has writen their own custom polymorphic serializer then Json will ignore it.
The descriptor and implementation in
PolymorphicSerializer
is simply a reasonable default for when neither the format nor the user has specified how polymorphism should work.
c
ok, for an example that's not polymorphism, but related
d
Hmm, I think I see what you're getting at.
c
for context, I'm writing a custom format, and find myself making these assumptions throughout, for things like checking whether something can be used as a map key, or introspecting polymorphic subtypes to check if the class discriminator has a conflict, same as JSON does
d
Ah, I figured. I also tried writing a custom format and had similar issues. Came to the conclusion that the library simply wasn't fully ready for custom formats. It does say custom format support is experimental.
c
yeah, but frankly it's been that way for quite a while now, so I'm half-expecting it to just sit in experimental similar to scripting.
d
The dev have been focusing on getting the K2 compiler out. I reckon they'll come back to this once that's stable. 🤞🏼
e
custom formats are all behind
@ExperimentalSerializationApi
aren't they? I don't get the sense they're ready for stabilization
d
Ah yeah for sure. Definitely nowhere near ready.
x
The existing API for custom formats is definitely very rough, but as @cypher121 mentions, it’s been that way for quite a while. It’d be nice to have a vague idea of when the rug will be pulled out from anyone using the existing API. “Experimental, but unlikely to change for a year or more” is very different from “it’ll have significant breaking changes every other week”.