Flatten to JSON - Allow any data type on the "anything" input

[matt.baker]

Suggestion: Allow any data type to be connected to the "anything" terminal of the flatten to JSON function.

Basically the same as the flatten to XML function.

Also the reverse, unflatten from JSON, may need to be done as well.

[drjdpowell]

I think AQ means an xnode or similar.  Where "reflection" is done once at edit time, rather than at run time.

[AristosQueue (NI)]

I finally have time to reply to this thread -- sorry for the delay... been catching a lot of glass balls and putting them back in the juggle rotation.

Powell summed up the bulk of my response. Each time you edit the class, you update the function that serializes that class and the one that deserializes the class. You teach the deserializer optionally to take care of older versions of the class that may be lingering in the world and mutating them into the current version.

Malia asks:

"How exactly do you create a reuse component that can serialize any JSON compatible LabVIEW type to JSON that would not need to query type information somehow from the reflection API?"

That is EXACTLY what my Character Lineator does. It has extension points for modifying the overall format (JSON/XML/Binary), modifying the particular formatting of fundamental types (period-vs-comma-for-decimals, timestamp-format, etc), and for the class to specify exactly which fields need to be serialized and mutation for deserialization. It's been used by multiple customers with great success, and I'm hoping to use it as the basis for all serialization in LabVIEW at some point.

The lineator API accepts type "Serializable.lvclass". Yes, your class must inherit from Serializable. That's not a weakness -- if a parent class doesn't support serialization, then the child class cannot support it either. Serialization is not like an interface where some mid-point of the inheritance tree can decide to add the ability. Either an object can save itself off (which includes its ancestor data) or it cannot. You cannot claim to reconstruct an object with only its child data.

Malia doesn't like any solution that requires actually formalizing his types as classes. That's fine. We can still write the "Serialize This Cluster.vi" function for any given type (and the matching deserializer), even non-typedefs. It's a one-time thing and it generates very efficient serialization (and deserialization) code. Ideally, we would have a scripting VI to generate it. I haven't written that scripting VI, but it is possible if someone wants to tackle it. And it would trivially beat the performance of the "Variant to JSON" solution that uses run-time reflection.

[drjdpowell]

The problem is that custom "Serialize this" VI's take time (and time is money) and are a potential bug point (if you forget to update your serialization code after you change something).  Scripting would be great, but there is a reason no one has done it yet; scripting is hard.   I've not done scripting but it appears significantly harder to do than Variant handling.  Variant type reflection will be much slower, I'm sure, but this matters little in a large number of cases.  

[AristosQueue (NI)]

I didn't say it was easy. I said it was more performant, more flexible, and generally more correct. 🙂

> but this matters little in a large number of cases.  

There are cases where it does not matter. This is true. Whether those are a minority or majority of cases, I am not prepared to say. In the case described by Malia, performance is a problem.

[drjdpowell]

> In the case described by Malia, performance is a problem.

But he (and I) might suspect that this is partly because of the type reflection tools provided are not ideal and could be improved with a little love from NI.

BTW, my own number one wish would be for a primative version of GetTypeInfo.vi that can be constant-folded.  That would save lots of time.

[AristosQueue (NI)]

You'd be a bit right that performance of reflection can be improved but ultimately wrong -- no amount of polish on reflection will get you anywhere close to a custom method. You can get close with some sort of JIT system.

[X.]

[drjdpowell]

JSONtext is now available on LAVA (eventually to be on the Tools network).  It effectively implements this idea (with the exception of LVOOP objects, which are embedded in flattened form).

[PBD_ctrl]

@drjdpowell Awesome tool!