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.

[wiebe@CARYA]

>Most histories are small... most classes don't set default values for fields. 

There are situations where non-default private data values are really convenient.

For instance, if an I32 represents an index (a cached search result maybe), it's default should be -1, not 0...

I'd have to search though all my classes, but I do change class's private data default values.

[avogadro5]

You just need to create the flattened strings once for each version as you create it. Then your tests should continue to pass as you add new versions or else you're going to need to do something custom in your deserialization.

---

I did say "headache" and not "impossible." You can also get creative with your folder structure and app instances to open 2 versions of a class at once.

[avogadro5]

avogadro5: deserialization is the encapsulation break, not mutation. If you're concerned about encapsulation breaking (and it is a reasonable concern), we need to disable the ability to unflatten from string entirely -- something I STRONGLY considered doing early on, making it mandatory for every class to opt into deserialization. If I can flatten the class to a string and then unflatten it, I can change the contents of that string before it goes to unflatten. If there's no semantic analysis of the unflattening, there's no guarantee that the object restored plays by the rules of the class.

---

There's a distinction here: I can sort of accept deserializing a class that has not changed since it was serialized (including the method code) and have some confidence that the private data was arrived at through the methods, assuming I trust the serialized data has not been tampered with. In other words it's unmodified from when it was serialized.

With the mutations, there's also the possibility a mutation was applied and I have arrived a condition that can't occur in the visible code, no mater how carefully I protect the data between serialization and deserialization. In my use case, I'm transmitting the data between apps on a network and it'd really just be better if the receiving app rejected data from an earlier class version so I know to go update the sender app.

My real problem here is visibility and customizability: if LabVIEW exposed the data that the serialized class instance *had been saved with* then I could write my own mutation code and conditionally reject incompatible older versions. Every OO deserializer I have seen provides a customization ability, and most are opt in. I recognize that information doesn't exist after the mutation is performed so I don't know where it could fit exactly, I guess on the connector panes of the various deserialize nodes, or add a "serializable" interface.

[Intaris]

On an interesting side-note, IIRC XControls include custom version handling code so that FP elements can mutate stored data on FPs.

The data stored on a FP for an XControl has a version number included. When initialising the control, the version of the data is available and can be converted as required.

[avogadro5]

On an interesting side-note, IIRC XControls include custom version handling code so that FP elements can mutate stored data on FPs.

The data stored on a FP for an XControl has a version number included. When initialising the control, the version of the data is available and can be converted as required.

---

This hints at the unstated reason customization won't be done: the custom mutation code would have to be able to run as a VI is loaded to unflatten data stored in constants and control defaults, in much the same way as XControls do. This is a very difficult time for LabVIEW where it seems debugging is not available and issues tend to lock everything up entirely. Anyone who's worked with XControls knows what a pain working in this space is.

[Intaris]

Regarding the "non-default" values....

There are two distinct cases. One is where the default value of any internal data field of a class is not the same as the default for that datatype.

The other is where you have an LVOOP constant somewhere with non-default object values.

For the second case, I feel myself thinking of the "update enum" methodology whenever a change occurs. But this would require some versioning internally (or hashing) so that we can somehow know if there's a difference of the saved data (whether we need to know WHAT the differences are is a different matter altogether) and then either promote the user with a "resolve" if done at edit time or break the VI if loaded dynamically at run-time.

[avogadro5]

For classes that are not persisting mutation history, what types of warnings/errors would you expect when operating with data? For example, do you think the right-click Data Operations>Make Current Value Default on class controls should be disabled? Or display a warning dialog if you use it?

---

No one answered this because a celebrity showed up... my personal preference is to allow setting defaults with no warning but I'd draw some inspiration from the dialog you get when a typedef is updated since typedefs already don't automatically mutate - any VI with an outdated non-mutatable default should be broken arrow until you acknowledge some dialog. The dialog could let you edit values but I know we don't like directly editing class attribute values, so it could be the only option is to reset to the default for the class and clear out the stored data to get the VI to compile.

If you attempt to unflatten a non-mutatable class with a different datatype from the XML/binary unflatten nodes you should get an error and the output should be the value you passed in for the datatype input. If the class data is in a variant you should get error 91.

And it's been suggested that the default will remain that new classes are mutatable, I'd just like there to be an IDE preference to reverse that for new classes.

edit: optionally, there could be a second option to opt out of serialization entirely - this would disable setting defaults or having constants with non-default values, and always error (either compile error or runtime) when wired into an unflatten node.

[Intaris]

I like the idea of having classes without serialisation. But this has many side-effects....

Dynamic loading of classes would no longer work which is a relatively large part of the LVOOP implementation as is.

But this has also many positive side.-effects. The ability to force inlining of an inheritance tree would be suddenly possible (like on FPGA) since the complete scope of the inheritance tree is known at compile time. I've made posts on this int he past and I think this would be a huge improvement and would suddenly allow us to use LVOOP on RT (Where we have some extreme performance requirements).

In order to implement this, I think there would almost have to be a second version of LVOOP in LabVIEW, maybe differentiatable via icon..... The two would be inherently incompatible with each other.

[avogadro5]

I think there's some confusion about what the serialization does exactly - it doesn't support unflattening a class that doesn't already exist in memory in the unflattening process (come to think of it, there's already an IDE error or warning if you have a "black box" constant/control that references a missing class - that might be what we need for "immutable" or "non-serializable" classes). If you think about it, that's actually only possible if you also include all contents (code) of that class and and any intermediate members of its inheritance tree - otherwise how would LabVIEW know what to do when that class instance hits a dynamic dispatch call?

Loading new classes at runtime is a different operation entirely - you can do it by opening a VI from disk that references the class, or with "Get LV Class Default Value.vi." So if you want a static inheritance tree you have to turn off dynamic loading of code.

[wiebe@CARYA]

> So if you want a static inheritance tree you have to turn off dynamic loading of code.

Turn off? You mean: don't do it?