Typedefs and Class Design

[blawson]

---

@jarrod S. wrote:

---

Daklu wrote:data and the convenience of data safety.

Contrast that with a class.  If I want to find where the Name field is read I can simply search for instances of 'Get Name.vi.'  Easy.

---

Unless you're using the new property nodes feature.

---

I believe those are searchable.  I just did a "find all instances" on one and it worked.  Since you can't open it from the BD, you have to open the accessor VI from the project first.  Or you can browse VIs in the Search dialog.

they save a ton of BD space if you're doing a few at a time. And they are pretty much an answer to Jack's desire for a public un/bundle of private data.  It doesn't take long to create them because they are pre-scripted, you can create them straight into a directory and then scope them individually, by property, or by virtual folders.  The files doesn't bother me, they're there if you need to extend them.  All we really need is the last 20% scripted: place text in the icon, create them automatically or en masse, default them to private, or a configurable default, or even set up a pattern (eg reads are public, writes are protected).

[Daklu]

---

@JackDunaway wrote:

---

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.

---

I want to rely on auto-mutation too.  Regardless of how much we want that, the current reality is that it's dangerous to do so.  Will I use auto-mutation for persisting objects to disk?  Yep.  Will I use it for objects that are critical to a properly functioning application or that store valuable customer data?  Nope, not a chance.

[JackDunaway]

---

Daklu wrote:

I want to rely on auto-mutation too.  Regardless of how much we want that, the current reality is that it's dangerous to do so.

---

Why is it dangerous? If you don't use typedef'd clusters or enums in your Class Private Data Cluster, and if you don't wax the mutation history by renaming the class, are there any more "gotchas" that make this dangerous?

(This question is not just for Dave.)

[jgcode]

---

@JackDunaway wrote:

---

Why is it dangerous? If you don't use typedef'd clusters or enums in your Class Private Data Cluster, and if you don't wax the mutation history by renaming the class, are there any more "gotchas" that make this dangerous?

(This question is not just for Dave.)

---

(I could be wrong but...) I am pretty sure if you have an older version, and load a new version, then new data members have default data values for that datatype (e.g. numeric = 0 etc...).

This can be problematic if you want/need certain values set when the version is upgraded.

[AristosQueue (NI)]

---

@jgcode wrote:

(I could be wrong but...) I am pretty sure if you have an older version, and load a new version, then new data members have default data values for that datatype (e.g. numeric = 0 etc...).

This can be problematic if you want/need certain values set when the version is upgraded.

---

Check LV documentation for more details. Short story: New data members are initialized with the default value that you supply for that control in the private data cluster. So if you add a numeric and give it a default value of 5, older version objects will unflatten and use the value of 5 for the new field.

Also, VIs do exist to allow you to explore the mutation history of an object:

              vi.lib\Utility\EditLVLibs\LVClass\Get Mutation History.vi

              vi.lib\Utility\EditLVLibs\LVClass\Set Mutation History.vi

The VIs have existed since LV 8.5. These could be used to build a nice UI for viewing and modifying the mutation records, if anyone is feeling industrious.

[Ben]

---

@Aristos Queue wrote:

...

Also, VIs do exist to allow you to explore the mutation history of an object:

              vi.lib\Utility\EditLVLibs\LVClass\Get Mutation History.vi

              vi.lib\Utility\EditLVLibs\LVClass\Set Mutation History.vi

The VIs have existed since LV 8.5. These could be used to build a nice UI for viewing and modifying the mutation records, if anyone is feeling industrious.

---

Well I'll have to update my To-Do list... probably right after I complete that garden train layout.

Ben

[jgcode]

---

@Aristos Queue wrote:

---

@jgcode wrote:

(I could be wrong but...) I am pretty sure if you have an older version, and load a new version, then new data members have default data values for that datatype (e.g. numeric = 0 etc...).

This can be problematic if you want/need certain values set when the version is upgraded.

---

Check LV documentation for more details. Short story: New data members are initialized with the default value that you supply for that control in the private data cluster. So if you add a numeric and give it a default value of 5, older version objects will unflatten and use the value of 5 for the new field.

---

As I mentioned above I could be wrong 🙂 - but I seem to remember data popping up in the wrong place ->

Would this still be the case if the Class contained a TypeDef and the Typedef got shuffled around/changed? (following along with the theme of this thread).  

[Daklu]

---

@JackDunaway wrote:

Why is it dangerous? If you don't use typedef'd clusters or enums in your Class Private Data Cluster, and if you don't wax the mutation history by renaming the class, are there any more "gotchas" that make this dangerous?

---

Here's how I understand it, based on various discussions over the years.  AQ or another blue can chime in if I've got something wrong.

Mutation history depends not only on the controls that are in the ctl file before and after the edit, but how the controls got there.  For example, replacing one control with another is a different operation than deleting the control and adding a new one.  That difference is reflected in the mutation history.  In the first case a persisted class' data can be auto-mutated; in the second case it cannot, even though the end result is the same.  As far as LV knows the new control is supposed to be an entirely new data type, so it populates it with the default value instead of the saved value.

How far does this extend?  I don't know.  The mutation process is too opaque.  If I delete a control and add a new identical control with the same name, have I just broken mutation?  What if I drag it out of the cluster frame and drag it back in?  What if I throw a rename and reorder in there somewhere?

It's not just renaming a class that resets mutation history.  Changing the class namespace at all resets mutation history.  Renaming an owning library or moving a class to a new library are, as far as LV mutation is concerned, just like creating a new class.  Being able to change source code organization is critical when refactoring.  If I'm relying on auto-mutation I am limiting my ability to safely refactor code.

One particular pet peeve of mine occurs when my mouse gets sticky in the project explorer.  Sometimes I'll click-release on an item but the item will stick to my mouse as if I were doing a click-hold.  I usually don't notice in time and end up accidentally moving whatever I've clicked on somewhere else in the project.  Often times the result is accidentally moving a class out of its owning library.

Uh oh... the namespace just changed.  I can't undo the move and I can't revert the ctl.  I can move the class back into the original library, but does that recover the mutation history?  Maybe, I don't know.  The only safe thing I can do is scrap the changes I've made to the class, close the project, and start over from the last save point.

The problem boils down to one of intent.  LV tracks the edits that are performed on a class to try and determine the programmer's intent.  Unfortunately humans aren't that predictable and choose many different paths to get from point A to point B.  Providing transparency into the mutation history would help, but as good as auto mutation is (and it is pretty good,) it can't address all the situations developers will find themselves.

[Daklu]

---

@Aristos Queue wrote:

Also, VIs do exist to allow you to explore the mutation history of an object:

              vi.lib\Utility\EditLVLibs\LVClass\Get Mutation History.vi

              vi.lib\Utility\EditLVLibs\LVClass\Set Mutation History.vi

---

I'm sure you've mentioned these before, but I didn't remember them.  Thanks for the tip.

[Daklu]

---

@Aristos Queue wrote:

Also, VIs do exist to allow you to explore the mutation history of an object:

---

So I just spent a bit of time poking around with those vis.  It looks like the Cluster Order Map is the key part of successfully mutating class data.  When new data is added it is given a value of -1 (well, a U32 version of -1) indicating that it doesn't exist in previous versions of the class.  As changes are made the Cluster Order Map is updated to map the class cluster item from the previous version to the current item, based on its order in the cluster.

The mutation history doesn't store any type information (aside from default value) for the controls, so I'm guessing that's obtained from the runtime object it is being converted into?  (Although converting a numeric from an I32 to an I64 does create a new mutation record.  Why?)  Control names appear to be irrelevant as far as mutation history is concerned.  Changing a name simply overwrites the most recent mutation record.  Perhaps they are need simply to map the data to the correct control at runtime?

I can see how access to the mutation history could help resolve some potential problems, such as deleting a control and adding a new one.  Old Name Index is reset to zero when the namespace changes.  I'm guessing the old names are stored as binary data in the lvclass files and erased when the namespace changes?  Wouldn't that would make namespace changes an unrecoverable edit?  Oddly, changing the namespace doesn't reset the entire mutation history.

Can you provide some clues as to what the Mutation Flags are?