Mutation History of Enums

[PJS]

My solution works through all of this... except that you must do two things.  Track the version of the class data and provide a migration technique from version to version.  Since you considered my solution (and the people who answered later with the very same thing.), you would should be able to get what you want quickly.  Misspellings or whatever are not an issue... I have been doing this for several versions of deployed code/LabVIEW now.  

I track the version of my class data/typedefs and deal with upgrades as necessary.  As I previously stated, it is a fair amount of overhead programing upfront, but now I have a palette of VIs specifically for dealing with this.  

[JackDunaway]

Thanks, all for the feedback. I was really there was some slick trick in LabVOOP for versioning enums that I was just not yet aware of, but no dice.

Let me continue the conversation with two related questions:

1. This is a "Best Practices" question for LabVOOP: Is it generally a bad idea to place an enum as a class member, given you expect to version the enum, and given you will be required to upconvert old versions of persistent data? Maybe I'm violating a "best practice" here...
2. If LabVIEW could automatically track mutation history of an enum and store this history as part of the control, would you use this language feature? (Given, the size of the enum on disk would increase 8 bytes to accomodate the four U16 version fields, and possibly, this "enhanced enum" would be a different data construct from the current enum, or simply manifest itself as a flag on the current enum that instructs the extra version information to be written when flattened).

[F._Schubert]

Just to go even a bit further, why not use GUIDs as an intermediate link between Literal and Number. Rings have this nice option to uncheck 'sequential values'. This would not only allow to have the GUID unchanged if it's only a spelling error (or you decide to use 'Init' instead of 'Start').

One thing I really miss is a concept of inheriting enums. So if I have my basic states for my state machine (Init, Deinit, Idle) and I think that I should also have a state 'error' in that list or think that 'Shutdown' is better than 'Deinit', no chance. With a good GUID we could write some tools to get a merging of enums...

Felix

[JackDunaway]

Felix,

I was tempted to mention signed enums and sparse enums as other features of a new "enhanced enum", but that's another topic saved for another conversation. What's your take on an enum control maintaining mutation history? Good idea? Helpful? Necessary? Would you use it?

[F._Schubert]

The enum is so important (state machines, action engines) and 'primitive' (as in primitiveType), I really would like to have it redesigned. Not just having a feature added, but really a redesign process that takes into account what we need the enum for (states, actions, messages) and makes this enum to a state-of-the-art OOP thing instead of the neighbor of the ring (what do they have in common from a user perspective? -> nothing, that's just a similar implementation that moved them in the same palette).

I'm going to vote for any idea making an enhanced enum.

Felix

[JackDunaway]

---

@f. Schubert wrote:

The enum is so important (state machines, action engines) and 'primitive' (as in primitiveType), I really would like to have it redesigned. Not just having a feature added, but really a redesign process that takes into account what we need the enum for (states, actions, messages) and makes this enum to a state-of-the-art OOP thing 

---

My perspective is not large enough to see a need for additional features other than sparseness, more datatype options, and mutation history. If you want to crosslink a new thread topic here, I'm interested in hearing more ways to improve the enum. 

[F._Schubert]

I think the feature requests are all what we as community can give to NI. It's the job of the persons with source code access to re-model the enum to the best. I'd like to have some inheritance/merging for enums. If I post it on the IE I'll link it here, and you please do the same and get the mutation issue posted so they take care of this.

Felix

[Intaris]

Would embedding each enum version in a different revision of a simple enum-containing class not help get around these problems?.

Just an idea.

[Ben]

My "gut" has kept me from uinsg enums in private data for the above listed reasons and since it seems to highly couple the user of the class to the class that uses it. Strings seem the natural replacement choice.

Silly pre-functioning cafine question:

Can the enum be replaced by a class and use dynamic dispatching like we would use the enum?

Ben

[F._Schubert]

I think the problem is when you wire the Enum-class to a case structure. You need to force the user to have a default state for enum values that are added in a child class.

I was thinking about an approach to define the enum inheritance or merge process in a seperate step. Afterwards the enum (mean the Type Def files *.ctl) are updated. Then your code might break in some situations and you go and fix it. But this also doesn't work, because removing elements from the enum and addig something might change but not break the code.

Felix