carnagion/gdserializer

An XML (de)serialization framework for Godot's C# API.

👋 Hi, I'm Indraneel

• I'm a computer science student 💻
• I'm interested in functional programming, type theory, and artificial intelligence 🤖
• I'm also a musician 🎸

gdserializer's Issues

Dictionary<TKey, TValue> is not guaranteed to preserve insertion order

The default serializer implementation (Serializer) uses a Dictionary<Type, ISerializer> to check for specialized serializers for specific types. The way a serializer is found (for a given Type type) is as follows:

1. Serializer checks if Specialized contains the type as a key. If found, that is returned.
2. If not found, Serializer searches for first Type that is exactly the generic type type. If found, that is returned.
3. If not found, Serializer searches for the first Type that inherits/implements the generic type type. If found, that is returned.
4. If no match is found, no specialized serializer is returned.

A closer look will reveal that steps 2 and 3 can lead to a hard-to-track issue.
What happens if there are multiple Types that inherit/implement the specified Type? Say for example, the specified Type is typeof(List<>), and Specialized contains both typeof(IEnumerable<>) and typeof(ICollection<>) as keys. List<T> implements both of these, so which one is chosen?

A simple answer is that whichever is encounter first in the linear search is picked. But Dictionary<TKey, TValue> is not guaranteed to preserve order, and therein lies the problem.
That could lead to multiple calls of this method with the same parameter leading to different results, even if Specialized is not mutated in between.

The only proper solution to this would be to use an ordered version of Dictionary<TKey, TValue> that preserves insertion order and allows insertion using indexes. A non-generic OrderedDictionary is already available under System.Collections.Specialized. A generic OrderedDictionary<TKey, TValue> would be ideal.

Member (de)serialization ignores actual type and uses member's declared type

When (de)serializing a field or property, Serializer uses the type that the field or property was declared as, not the type that's encoded in XML or the value's actual type.

Using GetType() (when serializing) or GetTypeToDeserialize() (when deserializing) would solve this issue, albeit at the cost of some performance.

StackOverflowException when initializing serializer

When creating a new instance of Serializer, CollectionSerializer, EnumerableSerializer, or DictionarySerializer, a StackOverflowException will inevitably be thrown.

This is due to the fact that the Specialized property in the Serializer class (which the other three inherit from) is an instance property, and also creates new instances of the other three upon initializing - leading to new instances being recursively created with no end.

This property originally used to be static, and was later changed to be an instance property.
Changing it back to a static property will fix the problem.

GetType() will fail if trying to get a type that is not entirely defined in one assembly

Assembly.GetType() works fine for types that are defined in that assembly.

But consider a type such as List<Node>. This is a generic type made from a generic type definition (List<>) and a generic type parameter (Node), both of which are from different assembly.
Which means that calling GetType("System.Collections.Generic.List1[Godot.Node]")onList<>'s assembly will return null, and calling it on Node's assembly will also return null`, since the resulting type is not fully from either assembly, but rather composed of types from both of the assemblies.

The easiest solution to this problem would be to avoid relying on GetType(), and instead retrieve an IEnumerable<Type> and find the first match by comparing type names.
This solution may be significantly slower since it would likely have to search through hundreds of types. Caching the results might help with this issue, but it may not be needed as (de)serialization is only expected to take place during loading and saving.

Collection and dictionary items are always assumed to be of the same type

As of now, CollectionSerializer and DictionarySerializer assume that the items in the collection/keys and values in the dictionary are of the exact same type as their generic type arguments.

That is to say, CollectionSerializer assumes that a List<A>'s items are all of type A, even if some may actually be of type B (where B : A). A similar assumption is made by DictionarySerializer when it comes to keys and values.

This is obviously not always going to be the case, and so it is necessary to ensure that the correct type is used during (de)serialization.
The most obvious fix is to simply include a Type attribute in the item, key, or value nodes as necessary, and prevent passing the item/key/value Type in case the Type attribute is found on said nodes. This will allow Serializer to (de)serialize them as the correct type.

Serializer for nodes removes `<Children>` XML without adding it back

As the title says, NodeSerializer removes the <Children> node so that Serializer can deserialize members, but does not add it back later - which means that if the XML node is deserialized again, the children do not get deserialized.