Circular references?

[d-markey]

Hello,

I like very much this idea, thanks for this proposition.

I have one question regarding custom and nested objects, and especially situations where nested objects create circular dependencies (Person B is in Person A's list of friends, and surely A will also be in B's friends! Brothers and sisters have at least one parent in common too).

This would require a serialization context to be passed around when decoding/encoding a full payload. Would you leave that aspect to implementers of the protocol or would it make sense to modify the interfaces and have the decode/encode methods accept an optional serialization context object?

Thinking about it, this could also help serializers that don't support circular dependencies (eg. JSON, CSV...) to detect such situations and throw an exception instead of eventually failing because of insufficient memory / stack space. So maybe a serialization context would be mandatory after all?

[d-markey]

Also maybe add encodeObjectRef<T>() / decodeObjectRef<T>() on Encoder / Decoder... Or leave it to en/decodeObject<T>() and en/decodeObjectOrNull<T>()?

[schultek]

I'm not sure how circular references would even look like in serialized form. Json doesn't support it, as well as any other format I know.

[d-markey]

Well, there are ways to do that by keeping track of visited objects and issuing a reference to that object during serialization, or yielding the object matching the reference during deserialization. There are a number of such mechanisms that have been implemented eg https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/preserve-references, https://docs.oracle.com/javase/8/docs/platform/serialization/spec/serial-arch.html#a4176, https://github.com/apache/fury