LabVIEW
LabVIEW Object to JSON
Hi everyone,
I was looking in the forums and I couldn't find a reason why the LV "Flatten to JSON" Function does not support LV Objects (Classes).
Apparently it does not work both in LabVIEW and LabVIEW NXG.
In LabVIEW Idea Exchange I've found the reasons why it does not support enums, paths or timestamps.
But why not LV Classes?
Regards,
@AllisonSCJ wrote:
Based on how classes work in Labview, I'm guessing it's something to do with the following
1. An object's data is private
Labview has no way to reflect on data in a private class to determine the names and values of the object.
Not a valid point! Flatten to XML does, it is also a primitive. There is also a toolkit JSON Object Serialization that does it too.
2. An object is closer to a variant than a cluster. You'll notice that variants also cannot be flattened to a JSON string. An object is represented by values, and meta data on its type similarly to a variant, with the exception that an object has only private data.
If you call Variant to Flattened String.vi with an input of an object, the flattened string gives only the object's name; Labview is privy to no other information on the class that it can expose.
Interesting point, but it does not support the first one, since you can use Flatten to XML to get private data.
A point: when you flatten an object to string, it gives you a sequence of byte strings that has a specific meaning for each byte, as stated in Lavag Forums.
So, I still see no reason why Flatten to JSON does not support objects.
It should be easy enough to implement in a class, but due to data being private it needs to be a class function.
Flatten to JSON as function: reads the object attribute cluster and converts to JSON.
@Yamaeda wrote:
It should be easy enough to implement in a class, but due to data being private it needs to be a class function.
Flatten to JSON as function: reads the object attribute cluster and converts to JSON.
Yes, it should be not so difficult. With LV2020 and interfaces, things can get even easier.
However, when using composition and inheritance, you'll need nested functions, and then it starts getting difficult.
Still, it is an alternative, but not an answer to my question.
@Jarrod_S. wrote:
The built-in JSON primitives have notable limitations, like not accepting variants, paths or enums. If you try to wire a cluster type in that has either of these, you get a broken run arrow.
Even if your base class doesn't contain any of these illegal types in its private class data, there would be no way of guaranteeing that some child class doesn't have one of these types. These child classes could possibly even be loaded dynamically at run-time, providing no way for the LabVIEW compiler to break the run arrow.
This might not be the reason that LV classes aren't supported with the JSON primitives, but it is an example of why they couldn't work today. Other primitives like Flatten to String don't have these type limitations, and can therefore support LV classes.
That is a very good point, and that could be the reason.
Do you believe a run-time error would be possible with these primitives? Although it wouldn't break the arrow, just throwing an error during the execution would satisfy most uses.
