Leaderboard

Takes a coffee break half way though. NI’s not paying it enough for “high performance”.

We, too, would very much like to serialize objects more easily. We actually do serialize objects to XML now, but we write a serialization method for each class (and this method calls the parent method, if applicable). Writing a custom method for each class is a fair amount of work and undesirable when there opught to be a framework that supports this automatically. (Note that the native XML functions do provide a framework that serializes objects, but the XML format is not satisfactory for all purposes, as stated elsewhere previously. In particular, if an object has a default value the generated XML just says that, rather than specifying the actual values, which makes the XML output to any application that doesn't have the exact same class definition. NI could just make a new version of their XML VIs that would format data better--which is probably pretty easy--and that would probably be a fine solution for many of us. In the meantime LabVIEW developers need to do this, and that is I think why we are having this discussion.) Using a cluster within an object will also work (we do use this approach, actually, with configuration files, although for this purpose we use the native XML VIs), although it doesn't support (I don't think) writing parent data or objects within the cluster. More importantly, there ought to be a way to serialize every object, not just a cluster within the class. (Using a cluster does negate some of the points of using an object in the first place, like maintaning history, although this is more important in some situations than others.) Mostly, I don't think developers should have to do this. It should be easy (trivial, actually) to serialize objects, in my opinion, to an interchangeable format such as XML. (Java and other languages have frameworks to do this. Why don't we?)