Leaderboard

We need feedback on our feedback!

I must say I appreciate when AQ comments on ideas, but as he says, "official" (or even semi-official) responses are few and far between. I would definitely prefer negative comments to none at all!

Yeah, and as soon as we implemented that, even more people would be complaining that when you change the name of a class that the file *doesn't* get renamed. I say this based on the screams and complaints that the project originally generated when renaming a virtual folder did not rename the folder on disk and moving a VI from one folder to another didn't move the file on disk. But beyond my wild speculation about the preferences of LV users, there's a very big usability problem with the GUID solution... file copying. How do you resolve the problem of File >> Save As? When a user does Save As, are they making a backup copy (where you'd want to preserve the GUID exactly) or are they forking a copy (where they'd want a new GUID)? When they have to recreate a missing class, how does a user fill in the GUID? Ok, you upgrade this to be a user defined name instead of a GUID. Great... now you have the same problem with misspelling the name that you had before making you want to change it. So that solves nothing. And further, now when you create a class you are prompted for the name of the class and the file name for the class. I'd actually recommend making them *not* match, otherwise you're going to get burned in the rare cases when they don't match -- I know this because it is exactly what happens to me right now in MS Visual Studio where the name of the class and the name of the file start off the same but someone may change the internal class name without renaming the file (generally because they don't want to mess up the source code control change tracking). LabVIEW made the opposite choice, and what we gain in clarity of file contents and findability, we lose in data preservation and source code control. Which is better? The debate about name handling in computer environments is endless. I have joked before that management of names is the primary job of a computer scientist. We, as code poets, must give to airy nothing a local memory address and a name. And my studies of mythology and history have taught me that renaming a thing is not done lightly nor without consequence. In the end, we picked a paradigm that seemed like it would work for most situations. It has its pros and its cons. If you *really* want a solution, do this: Save every individual .lvclass file inside its own .llb. That gives you the ability to rename the file on disk without changing the class name. It won't help the data unflatten case because that's the data name and any layer of indirection there leads to the GUID problems, but it will help with the source code control name change problem. But I promise you, you'll be ticked off by it, just like I am in MSVS, just as soon as the file name stops matching the contained class name. Trust me. The presentation is now available. http://zone.ni.com/wv/app/doc/p/id/wv-2003

This was precisely the reason I brought up this point yesterday - people are not aware of this issue and it's very easy to get bitten. The problem is that this declaration is done by name. There are legitimate reasons for wanting to change a class name without wanting to lose the history, so it would have been nicer if this was some sort of GUID and we would get the option to reset this GUID when renaming the class. Here are some examples for legitimate reasons: Code distribution (Daklu's case). Spelling mistakes (Oh, I forgot to type the F in "shift"?). Changes in the class subject (I first encountered this issue when The Device was nearing the end of the development and marketing gave it its final production name. "OK, I'll just rename the class", thought I). I would really like to avoid this. The class name is supposed to be descriptive and having different names will just create confusion (see case 3 above). For further reading, you may wish to have a look at the preserving class data document: http://zone.ni.com/devzone/cda/tut/p/id/6316

Yes, it sounds like you have the right of it. Yes, but it wouldn't help you.You have A.lvclass at version 1.0.0.4. You save lots of data. Now you rename the class to B.lvclass. You certainly could bump the class version in the file from 1.0.0.0 to 1.0.0.4. And you could cut and paste the mutation history from A.lvclass to B.lvclass. That's great -- you now have a version 4 of B that can load any data that was flattened as B versions 0, 1, 2 or 3. The problem is that all of your data was flattened as *A*. The name of the class and the version number are both part of the flattened data. It has to be because when I flatten data on an A wire, that data might be a child class like ChildOfA.lvclass. When I unflatten data onto an A wire, the data has to declare which class it represents. So, yes, you could preserve all the mutation instructions of your previous class on the new class, but it doesn't make any of your data accessible. To be able to unflatten old data, you have to be a new version of the same class and "same class" means same name. This also has ramifications for people who use the Application Builder options to add a prefix to their files as part of the build. You should stop using that option if you want data versioning of class data to work from one version of your distribution to the next. Otherwise every distribution you produce is version zero because the class is just brand new renamed. The presentation isn't posted yet. When it is, it'll be linked from here: http://decibel.ni.com/content/docs/DOC-8462