I’d actually recommend deriving it from this class: https://lavag.org/files/file/216-json-labview/
If we do this, we get a ton of benefits. You can set key-value pairs directly on the object, serialization is handled efficiently for us (the library is good) and the objects are composable in a way we currently do...badly. That is, you can store one of these json items as a child of another one, so we could have a json object representing the entire data structure and then the keys would be GUID:{data}. We’d have to manually add in things like the version, but that could be handled during init. This has a side effect which I’m not sure is positive or negative – since everything is just a json object, it can be constructed and deconstructed without actually knowing anything about the class that generated it.
Alternatively, keep the class hierarchy as is but add a "to/from json" function which allows reinit from a json object and saving to a json object rather than a string.
I’d actually recommend deriving it from this class: https://lavag.org/files/file/216-json-labview/ If we do this, we get a ton of benefits. You can set key-value pairs directly on the object, serialization is handled efficiently for us (the library is good) and the objects are composable in a way we currently do...badly. That is, you can store one of these json items as a child of another one, so we could have a json object representing the entire data structure and then the keys would be GUID:{data}. We’d have to manually add in things like the version, but that could be handled during init. This has a side effect which I’m not sure is positive or negative – since everything is just a json object, it can be constructed and deconstructed without actually knowing anything about the class that generated it.
Alternatively, keep the class hierarchy as is but add a "to/from json" function which allows reinit from a json object and saving to a json object rather than a string.