User | Kudos |
---|---|
18 | |
17 | |
10 | |
5 | |
3 |
Classes suffer from the following:
Classes are identified by their name.
Renaming a class results in a loss of identity history. The version history is reset
The name consists of the file name and all the libraries the class is nested in.
Moving a class into or out of a library counts as a rename of the class.
So what is the issue with this? Any method you use to save the class data to a file (datalog, xml, flattened string...) will contain the class name (including library position) and the version. If you move/rename the class this data will change and your externally saved class data will be unreadable.
Also using classes in packed libraries will result in the classes being renamed (lvlib-->lvlibp), but the classes will retain their version history. Still, the rename makes saved data unreadable.
I propose that we introduce a static class ID that persists through all the above operations. I'm thinking something like a Class GUID. This GUID would be created together with the class and would be read only. It would be good if Get LV Class Name.vi would return the Class GUID and if you introduced a Get LV Class Default Value By Class GUID.vi (Class must be in memory). All the operations that saves/flattens etc. and currently uses version and name should then use version, name and GUID. On load/unflatten the name would not be used at all, only the GUID and the version.
If this was implemented:
The version would never be required to be reset. As long as the GUID persists the version can remain.
Saved class data would not become corrupt upon trivial operations in the project. As it currently is you cannot move a class out of a library and restore it to the same position/name without corrupting your saved class data (unless the class version is 1.0.0.0 already).
You would get fewer complaints regarding the OOP implementation.
So there are some problems with doing this. I'll list possible solutions along with the problems:
What should be done on a rename or library relocation:
Version should be incremented retaining the old name. GUID stays the same.
What should be done on a “Save as” - “Copy”:
New GUID created for the copy. Save as will prompt you to retain version history or reset the version to 1.0.0.0 (if you can find find a way to do this), or just reset the version.
What should be done when a class is copied in internet explorer and loaded?
This is currently very very bad for labview, and thus never done.
But now we can detect that we have multiple GUIDs and a pop up should be displayed with a list of all duplicates. There should be three choices for each group of duplicates:
Retain GUID, only one can select this
Get new GUID and prompt for class rename – version history handles as in 2.1
Don't load the class and discard the operation adding it to the project.
What should be done when both a class from a packed library and the library that was packed are trying to be loaded at the same time:
They have the same GUID, prompt the user to choose which to load, only one can be loaded at any time.
What should be done with the version numbers when packing a class in a packed library:
Original has version incremented twice, all version have the same data. Example:
Original class version = 1.0.0.4
Packed class = 1.0.0.5
After Packing original is = 1.0.0.6.
The major issue with this is probably that it'll increase the overhead on all classes, right? So it doesn't have to be a GUID, but some form of uniqueness should be attributed to the class because the system is extremely inflexible in the current implementation.
Please don't propose that I implement methods on all classes that saves the private data piece by piece as a work around. If that was the intention that NI had with classes then wiring a class to a flatten/save etc. node should result in a broken wire.
I might have been overly thorough with my explanation but this is a big issue for me due to CAR543330 where the work around is reducing the size of my libraries, which is really really hard when they contain classes that are also saved to a large number of external files.
Best regards Henrik
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Increasing-class-flexibility-by-adding-a-unique-class-...