I suggest NI include a native feature to serialize LabVIEW objects in an interchangeable form. (Alternatively, NI can at least provide enough access to allow a third party to develop such a framework.)
By "interchangeable" I mean in a manner that allows sharing object data between platforms (e.g., between LabVIEW and Java). (Hence having "default data" without specifying the values of the default data is not allowed.) Moreover, using a more common format (such as "Simple XML") is appropriate.
Of course, including the object version number is only meaningful within LabVIEW, but this is useful within LabVIEW thanks to the capability of LabVIEW objects to translate between versions. (Note: I recognize the versioning can't avoid all possible issues, but in practice I think that is rarely a practical issue.)
I understand that for security reasons a developer may want to turn off the ability to serialize an object. To support that, I envision a checkbox to allow serialization (default = True) in the class properties dialog.
I think XML is the best option for this for several reasons:
1) It is a common way to serialize objects in different environments. This means that I can exchange serialized data with Java applications, for example.
2) It is readable, albeit not easily readable, by human beings. (I actually don't want humans to read serialized data very often--and really never the operator, but it is good that they can on the rare occasion when they need to do so.)
Why I think NI should implement this:
1) This is relatively straightforward for NI to do since NI can already serialize a class to the current (noninterchangeable) LabVIEW XML format.
2) Having this capability could greatly expand the application space of LabVIEW, since it would make it orders of magnitude easier to interface with nonLabVIEW applications. This is especially important in large systems, in which it may be advantageous to implement some system components in one environment and other components in another environment. This is, I think, by far the most compelling reason to include this feature.
3) That there is a need for this seems obvious, given the number of lengthy discussions just on LAVA about this topic.
4) The current situation, in which each class must contain specific code for serialization, is patently inefficient and nonsensical.
5) In other major languages meaningful object serialization is a given, and LabVIEW should include (indeed, must include) this functionality to be competitive.
For the record, to serialize LabVIEW object data for communication within LabVIEW we use either the methods to flatten to string or to XML, and this works fine. I realize it's not theoretically 100% fool-proof, because of potential issues across different object versions, but in practice we use version control, so that we build applications using the same versions of interface code (usually), and we only have one large system, so we can pretty easily control our deployed applications. (I think that versioning an application could achieve the same.) In practice, we've never experienced a version problem with this approach, and it avoids having to write any class-specific code (which, again, a developer should definitely not have to do) to support serialization.
).
