Trade-offs were made for speed, less allocations, and also clean integration with our serialization system. Thereâs other work we have to do first to get dictionary support in.
You should approach FullInspector/FullSerializer developer. This guy has made so much work on Unity serialization and he is able to serialiaze pretty much everything in json (dictionary, interface, inheritance, generics âŚ).
Unity must hire this guy and give him the chance to improve the core engine
Like it was said above and was said elsewhere they want to first have as efficient and light weighted support they can at start and not to bloat it with every feature a man can think of. Itâs not really lack of skills or anything. There are already a lot of full feature set libs out there for free and paid.
We know that but many many people will use it to consume third parties web services where you canât have control of the JSON output and itâs really common to have âDictionaryâ like random structures.
Im afraid my line of thinking goes in the same direction. JsonUtility seems like a mere anecdotic class. Currently the feature set can only work with an object. From and to Json, only supports an object.
If you have a Json string with an array of objects, wont work. Letâs not even mention nested arrays. And json is basically keys value pairs, but deserializing to a dictionary seems to be asking for âslow bloatwareâ.
I was exited about replacing third party dependencies, but resulted tough to find that my very basic needs, deserializing an array of objects, was too much to handle for the Unity API.
Everything in Unity is made to be extended and improved. Itâs part of what makes it shines. Trust me, you donât want to depend entirely on one company to create your game, especially Unity. We have fast turnarounds when it comes to fixing bugs with store packages, but with Unity, fixing one big bug can take several months.