Typedefs and Class Design

[JackDunaway]

---

Daklu wrote:

Given the limitations, I think it's a mistake to rely on that feature if the saved object is critical to the application.  As Jarrod said, it's much better to roll your own Serialize method.

---

I just can't accept this. I want to be able to rely on auto-mutation, even for mission critical apps. GIVEN: I only rely on auto-serialization/deserialization when I do not need access to data that was dropped from the structure and I don't need to set a run-time custom value for new values. Now, if custom mutation is required, there's no question you're relegated to a homebrew method.

For the future: I agree with all that access to the auto-generated Serialize and Deserialize methods should be available for classes. We have it for XControls!...even though they lack the feature of automatically scripting the mutation routine. I would like to see the best of both worlds.

For the future: Based on discussion thus far, it seems like a bad deal that clustered typedefs cannot reside in the Class Private Data Cluster. It seems like overkill to create a class and accessors where a simple structure will suffice that has globally accessible members. I could see two solutions to this problem: 1) If callers could use Bundle/Unbundle By Name on a class marked as "Globally Accessible", I would not mind creating a "class" where a "typedef" used to be, since it would be just as easy to use and encapsulated in only one file., or 2) Develop typedefs such that they all maintain a mutation history (not just enums). I lean toward suggestion #1 (someone must have suggested this elsewhere, please provide a link because I can't find discussion on the topic)

[JackDunaway]

---

@JackDunaway wrote:

I could see two solutions to this problem:

---

Make that three solutions: 3) Have one more data cluster associated with classes that's the Class Public Data Cluster, or simple have one Class Data Cluster with members marked as Private or Public. Public members could be accessed using Bundle/Unbundle globally, whereas private members could only be accessed using Bundle/Unbundle within the class (the current behavior for all data members).

This would also obviate piddly accessors that inflate the number of VIs in a project and deflate the node-to-file ratio.

[Ben]

"hold da bus!"

Reading/writting type-def'd cluster has always been a challenge as illustrated in my "what the hell where you thinking Nugget?" found here (that BTW does not use black magic and is open to your whims).

Jsut becuase we stick them in a Class does not cure that ill.

Prior to LVOOP we (at least me) never expected LV to handle the cluster def changes and have writtin code to handle just this issue.

So LVOOP is still cool and Type defs are still type defs.

The big sticking point as highlighted by Michael is restoring the class from disk when it has a type and the type def has changed.

For my part, i will keep that "pit" in mind as I code. I'm sorry it hit Michael but I am glad you warned us.

Thank you,

Ben

[F._Schubert]

Gained some new insights:

1.)

A cluster is a 'primitive object', that only has attributes. No operations, no inheritance, no class-object abstraction.

When you type-def a cluster, you introduce the class-object abstraction, your type def is the 'class definition'.

Now the class supersedes the type defed cluster by introducing methods/operation, access scope, ...

2.)

Making a super-cluster (type-defed cluster of type-defed clusters) transforms to a composition (a class that contains other classes).

But OOP gives you a new option to combine clusters: through inheritance. Here you add the parents private data cluster to the childs private data cluster.

Also gives you some new options to better combine them, as private data (no protected or public accessors) is kept out of the childs access. Same with the composition, where you only get access to the public data (in some cases also the protected data in LVOOP).

Felix

[Ben]

Felix,

If you keep making posts like that, the non-LVOOPers out there will start using LVOOP and cats and dogs living together.. "oh my!"

Ben

[AristosQueue (NI)]

There's another alternative that no one has mentioned -- use the typedef'd cluster, just don't put the typedef'd cluster inside the class private data. There's no reason why a typedef'd cluster can't be the data type of an accessor VI. Just when you set the value into the private data, unbundle both and write the fields of the typedef'd cluster to the fields of the private data the way they need to be mapped. Inverse for the get accessor.

(Though ultimately my own sympathies lie with Felix's post.)

[PJM_JKI]

I know that I am going to go on a slight tangent, but I shudder when I see replacing all cluster typedef by class being advocated.

It is my belief that one should use classes only where there is an overwhelming advantages over not using them.

Quick example. If took over a code written by another developer and I see a cluster, I know how this will be used/accessed all throughout the code. Now, if instead I do see a class, I need to find out a lot of informations before I can know how this is used in any given VIs. This take a lot more brain power since this is essentially adding a new data type that has its own rules and "regulations". Now repeat this all over the place where you use to have typedefs and the resulting code will be in my opinion a lot harder to understand and maintain that plain vanilla LV code using typedef.

Note: I am using LVOOP classes in my code all the time (in moderation), but I don't anticipate not using cluster typedef (in favor of a class) anytime soon (if ever).

In regard to mutation, I don't expect LV to ever being able to provide successful mutation for my persistent LVOOP data. This is just too complicated of a problem.

[Jarrod_S.]

"Can you share what conventions you've established?" @Daklu: We have a general purpose storage library that serializes to XML. The storage is a hierarchical tree structure where each node has an arbitrary set of property name/value pairs. The property names are strings and the values can be many different basic data types like double, I32, string, etc. This storage is flexible enough to be used across multiple different classes, because it doesn't dictate the format of the hierarchy or the data fields used by each node. We use this data structure to store the data and read to or write from file. It contains a version number in the saved format. When reading it from file, the data may need to pass through various stages of mutation (1.0 -> 1.1 -> 2.0, etc.) before getting to the final version. Sorry, not much else I really have to share. But from experience I can say that once we had this storage put together, it made life much much easier.

[JackDunaway]

---

PJM_JKI wrote:

In regard to mutation, I don't expect LV to ever being able to provide successful mutation for my persistent LVOOP data. This is just too complicated of a problem.

---

It's often not a complicated problem. Based on my own history of versioning data structures, one common mutation is adding new elements and using the default value for those new elements (think of AQ's webcast with adding the timestamp). Why not offload mundane, repeatable, ugly-code tasks such as this to a background procedure? It's a feature of LVOOP - if nobody's going to use it, why was it even created? I'm surprised at how few people seem excited about auto-mutation - should I be leery myself?

Plus, if you're going to roll your own Serialize/Deserialize methods that follow around a typedef, havn't you in essence created the need for a class (you know, a data structure with methods that act on it, and a few old versions of .ctls that would become privately scoped)?

(Again, I'll point out, I lean toward LabVIEW automatically scripting the Deserialize/Serialize versioning routines, just make them two user-accessible methods in the class)

[AristosQueue (NI)]

---

@PJM_JKI wrote:
If took over a code written by another developer and I see a cluster, I know how this will be used/accessed all throughout the code.

---

I doubt this is true.

Many clusters have rules for how they should be used -- one element is always greater than another element, or some boolean element is always true if condition xyz is met by the other elements, etc. Even something as simple as a Rectangle cluster has rules for what actually indicates a valid rectangle -- left less than or equal to right, top less than or equal to bottom. Oh, except in this application, left is supposed to be strictly less than right and top is supposed to be strictly less than bottom. But you can't know any of that from just looking at the type of the wire, and it is rarely documented in the Context Help for the type, and even when it is, you can't know that the CH is actually up-to-date with what someone has done in code.

The only clusters that you know their usage are the ones that are "options bags" -- blocks of totally disjoint options settings, like the ones frequently seen for configuring hardware: this channel, this sample rate, this frequency, etc, where every option can be set to any value and doesn't conflict with the others. Those clusters do not appear to be so common, in my observation.

In other words, the clusters already have their own rules and regulations, they just aren't documented or enforced. You still have to learn them. At least with the classes you can look at a fixed API and see what restrictions are enforced.

In LV 2010, classes are still a bit cumbersome and have a few edges that make them heavyweight for developers to actually create. But, my opinion, typedef clusters are dinosaurs and the meteor is in the sky.