Polymorphic TagSerializable

The current pattern for polymorphic serialization using TagSerializable requires a public new static Func<TagCompound, T> DESERIALIZER field on every subtype. This is an unnecessary and counter-intuitive pattern for subclasses that don’t change the serialization contract. The current static DESERIALIZER pattern was created as an attempt at “class level polymorphism” to allow classes to define their deserialisation method (normally call the appropriate constructor).

There is also a lack of documentation on correct use of the serialization system.

• TagSerializable should be used for your own classes
• TagSerializer should only be used for classes you don’t own (eg, Point in another library) or structs

There are several possible solutions to the inheritance inadequacy

1. Let a DESERIALIZER field on a parent class function for retrieving instances of the children if not ‘overriden’
   • This requires that the modder use TagSerializer.GetType(tag.GetString("<type>")) and call the appropriate constructor via reflection.
   • Should the TagSerializableSerializer enforce that the returned type is the same as <type> and how would that interact with refactoring (where Get<T> is called and T is not a parent of the type stored in <type> so <type> is ignored so the DESERIALIZER for T is called and allowed to re-interpret the data to match the requested type. (My intuition is that refactoring and inheritance don’t mix under the current system unless the modder uses reflection and some kind of old -> new type mapping in their DESERIALIZER
2. Allow a constructor with a single TagCompound parameter to take the place of the DESERIALIZER field.
   • This should probably be implemented anyway. It has the downside that the constructor must be explicitly overriden in all subclasses, but this is much more intuitive.
   • The reason this option wasn’t chosen in the first place is it doesn’t allow for as much flexibility deserializer implementation, but it should probably be the default for most modders and documented as such.
3. Create an extension of TagSerializable like TagSerializableAuto (can’t think of a good name at the time) which defines an additional void Deserialize(TagCompound) method, and calls the default constructor

[Chicken-Bones]

Everything discussed here stands, but given the lack of discussion I assume it’s low priority for the amount of work it would require. Polymorphism is only used by the few experienced devs in the community and they’re also probably quite capable of working around it for now. If this message gets 15 upvotes, I’ll change it to high priority.

[Jofairden]

I approve, [DontSerialize] or [NonSerialized] IAutoTagSerialized

What about NonSerializedAttribute ?