Make Class Mutation History Optional

[crossrulz]

This topic keeps coming up randomly.  A LabVIEW class keeps a mutation history so that it can load older versions of the class.  But how often does this actually need to be done?  I have never needed it.  Many others I have talked with have never needed it.  But it often causes problems as projects and histories get large.  For reference: Slow Editor Performance with Large LabVIEW Projects Containing Many Classes.  The history is also just added bloat to your files (lvclass and any built files that use the lvclass) for something most of us do not need and sometimes causes build errors.

My proposal is to add an option to the class properties to keep the mutation history.  It can be enabled by default to keep the current behavior.  But allowing me to uncheck this option and then never have to worry about clearing the history again would be well worth it.

[fefepeto_kb]

Couldn't agree more, but I think I can extend the idea with one more thing: add an environment option to turn it off for new classes. It would further reduce the burden by not having to uncheck the option for every freshly created class.

[wiebe@CARYA]

(For lack of documentation,) I never understood how this 'automatic data updating' should\would\does work in practice.

How it works is rather important to make educated choices, but it's left out as an 'exercise for the user'. This makes this expensive feature quite obscure.

I think it internals are best described in US7730450B2 - Automatic versioning and data mutation of user-defined data types - Google Patents, but haven't studied it yet.

Of course, the actual implementation might be different 🙄.

[fefepeto_kb]

I read trough just the summary and took a peak at the images, but my understanding is:

• If the class data has been extended all the existing objects saved with the old version will load their data and get the default of the new properties
• If the class data has been modified by deletion of properties then the old objects holding the old properties of the class will have them removed when loaded with the newer version.
• If the data types have been modified, then the old objects will have their data overwritten with the new type, although it's not clear if there is automatic conversion going or simply using the default value for these properties from the class data.

Also I think it would be useful to decide which versions of the class shall be included in the mutation history: i.e.: during development it might be important to keep all revisions, so the development process goes smooth, but during releases it would be nice if only the previously released version(s) and the latest version would be included. Although it is only important if the user of software is using it for development and has code that holds older version(s) of objects instantiated from the class (constants on the block diagram). For applications that are released as a whole and the users are not adding any code the mutation history does not add any value.

Seeing the inventor for the patent, and knowing that he has left NI according to his LinkedIn profile and also NI forum account, I doubt that these changes could happen. It is more likely that we could get an option to have mutation history or not.

[wiebe@CARYA]

>It is more likely that we could get an option to have mutation history or not.

Yes, I kudo-ed the idea.

I doubt I will ever have class mutation history on. I clear them often (manually).

[fefepeto_kb]

I just wanted to make sure that anyone, including me two weeks later, does not get carried away by wanting more from the idea than what is realistic 😄. The idea definition is great in the official post and I think, also hope, many will stand behind it.

[avogadro5]

I'd go farther and say the mutation history feature should be removed, or at least extended with a capability for developers to define the mutation code. There's the harm of the side effects of having the mutation history, and also the harm of a poorly understood/defined mutation protocol. I'd rather just get an unflatten error, or at least know if the data was mutated.

[crossrulz]

I understand your feelings of completely removing this feature.  My gut reaction is also that it should be completely removed.  But knowing the person who created LabVIEW OOP, I have no doubt it is in there for a reason.  That's why my suggestion is the bare minimum: making it optional.  I would like NI to add hooks so they can get data on how often the mutation history is actually used.  If the data shows it is extremely rarely or never used, then NI should consider simplifying their code base by removing the feature.

[fefepeto_kb]

@avogardo5 I might be misunderstanding your concerns, but I think there is a good enough description here: Preserving LabVIEW Class Data - NI

This is a link from the link in the original post. 

>extended with a capability for developers to define the mutation code

Based on the link above you can at least select which versions of the mutation code are preserved. Giving further options to the developers might lead to confusion, at least in my opinion. If, for example you could change the version of the controls inside the class the existing constants might easily become broken and unusable. Then, the solution would likely be what the class mutation history provides automatically: preserve the existing data and update it with from the classes current version.

The other possible explanation would be to only have specified properties of class stored in constants, but then why not just make a parent class? I understand that it is a little more work, but can definitely see the advantages in the long term maintenance.

In general, I'm against using class constant for anything but specifying the exact child class to be used for dynamic dispatch VIs.

[wiebe@CARYA]

>@avogardo5 I might be misunderstanding your concerns, but I think there is a good enough description here: Preserving LabVIEW Class Data - NI

It describes intend, but not how it works and it lacks details.

It's a good attempt, but we need the gory details. All of it, having 95% of the details is pointless.

There are so many ways to manipulate a cluster, those details are important. Or at least I suppose they are, because it's not explained. 

For example:

"If you add an element to the cluster"... What if I replace the entire cluster with a copy that has an extra element? Will that be managed?

"Any edit that changes the data type of the private data cluster bumps the version number of Alpha." Any edit? So when I add, delete, add, delete something, the version increased by 4? I don't think so.

"If you reorder elements in the cluster, " Reorder how? If I drag a control out of the cluster and into it, is that a reorder? Or a remove and add? Reordering a class's private data has never not crashed LabVIEW for me, so I learned not to use it.