1

So, firstly, I cannot use 'dynamic' as this is ultimately going through a IL2CPP transpiler that doesn't support dynamic language runtime (DLR).

That said, I'm writing a client intended for other developers to use that consumes a very generic API that allows for, including other things, defining/updating properties whose value can be any valid JSON type (string, number, array, nested object) as well as listing out all the properties that exist and their values. The following array elements could conceivably be modified during runtime of the application. I'm trying to figure out the most ergonomic way to deserialize something like the following in C#:

[
{
    "_id": "43534253"
    "value": {
        "name": "named thing",
        "address": [
            "Address Line 1",
            "Address Line 2"
        ],
        "location": {
            "lat": 50.123456,
            "long": -78.34
        }
    }
},
{
    "_id": "2345324",
    "value": {
        "a": "hello world",
        "b": 188.40723030755805,
        "c": 260
    }
},
...
]

To be clear, a further constraint however is that these are not the only two value types for "value". This array is the result of requesting "all the variously typed properties you've created through an API and their values". A devs next call may be to create a new property with

value: 0

which would add a third element to the above array with a value that is a number.

argyle
  • 1,319
  • 2
  • 14
  • 28
  • What is the intended use of the deserialized data? Do you know what to do with it given that you don't know its structure at compile time? – silkfire Mar 22 '19 at 20:00
  • There's already a popular library for this: https://stackoverflow.com/questions/6620165/how-can-i-parse-json-with-c – Display name Mar 22 '19 at 20:01
  • And there's this: https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-serialize-and-deserialize-json-data – Display name Mar 22 '19 at 20:02
  • It's a client to consume a generic 3rd party API and the purpose of the data at runtime would essentially be to extract the data to drive all kinds of logic. The API being a sort of "database" for these properties which itself can trigger custom definable logic when they change. – argyle Mar 22 '19 at 20:05
  • A `Dictionary` (that can itself hold `Dictionary`, nest at will) is the most general, if also the least convenient way of doing this if you have no access to dynamic structures. From the description, though, it sounds like you're trying to reinvent your very own JSON document store. Those already exist; consider just using something like MongoDB so you have an *actual* database instead of "sort of". Also, I'd never heard of IL2CPP before, but it sounds like something that has little reason to see continued use in this day and age of .NET Core. – Jeroen Mostert Mar 22 '19 at 20:39
  • @JeroenMostert This API is backed by a MongoDB, nevertheless, it is a 3rd Party API meant for accomplishing a particular class of things that have been built around that MongoDB, such as triggering scripts in a scalable compute environment when properties are updated. As far as IL2CPP goes, this is something that Unity does when compiling code to run on, for instance, iOS/PS4/etc and there is certainly a place for it. – argyle Mar 22 '19 at 20:42
  • 1
    Well, .NET Core definitely does not support the PS4 yet, and likely won't for quite a while to come, that's true. Given those restrictions, dynamically generating typed classes for on-the-fly compilation would not be easy either -- but presumably you wouldn't need that either. Nested dictionaries is just about the only way to go; use any JSON parsing library that will run on your platform and prepare for a lot of annoying code of the form `switch (Type.GetTypeCode(value.GetType()))`. (Alternatively, you could use libraries that offer discriminated unions to make this slightly easier.) – Jeroen Mostert Mar 22 '19 at 20:52
  • @JeroenMostert Yeah, I feared that. I asked the question in case there was a better way that I wasn't thinking of. – argyle Mar 22 '19 at 20:58
  • 1
    Oh, alternately (I'm a dum-dum) if your API essentially does not process the values itself at all, and just regurgitates them creatively to consumers, you can at least keep all primitive values as raw `string` values. Whether it's `0`, `"hello world"` or `["value1","value2"]` then need not concern you; you only need to keep track of the outer structure and distinguish between strings and dictionaries. (Parsing still requires a proper library; do not be tempted to take shortcuts there, as it would be very easy to get wrong. But after parsing, you can just keep the serialized forms.) – Jeroen Mostert Mar 22 '19 at 21:01

0 Answers0