Typedefs and Class Design

[Daklu]

"If I delete a control and add a new identical control with the same name, have I just broken mutation?"

Yep.

"What if I drag it out of the cluster frame and drag it back in?"

Nope, having the control outside of the frame is a compile error, and it appears mutation history isn't saved unless the class can compile.

"What if I throw a rename and reorder in there somewhere?"

Not tested extensively, but as long as the control isn't deleted from the ctl panel LV appears to handle these changes well.

"I can move the class back into the original library, but does that recover the mutation history?"

Alas, no.  Once you move the class out of the library you're done.  If you need mutation history go back and start again from the last save point.

(Okay, now I'll shut up for a while...)

[AristosQueue (NI)]

---

Daklu wrote:

"I can move the class back into the original library, but does that recover the mutation history?"

Alas, no.  Once you move the class out of the library you're done.  If you need mutation history go back and start again from the last save point.

---

And the reason is that any name change to the class resets the version to 1.0.0.0, because it is now a new class, and moving the class out of the library changes its qualified name, so moving it back in just changes the name again. You'd need the project to support Undo to undo that name change.

[crelf]

---

@JackDunaway wrote:

The "always typedef your clusters" mentality is driven into skulls from Day One of traditional LabVIEW best practices. 

---

Ugh, any "always" in programming is usually a poor statement - if it made sense to do that, then there'd be an entry on the idea exchange to lock it down (or it'd already be included in LabVIEW).

[Daklu]

---

@Aristos Queue wrote:

And the reason is that any name change to the class resets the version to 1.0.0.0, because it is now a new class, and moving the class out of the library changes its qualified name, so moving it back in just changes the name again. You'd need the project to support Undo to undo that name change.

---

I was originally thinking it may be possible to alter the latest mutation record and change the version number back to what it was previously +0.0.0.1.  But since that isn't possible I was left wondering why the namespace change has to be committed as soon as it happens?  Other actions aren't committed until the lvclass file is saved or changes are applied.  Can't the namespace commit be postponed as well?

Then I realized that would cause inconsistency between what the user is seeing in the project window and what the class' real namespace is.  Not only that, but (I think) postponing the namespace commit would make it impossible for unsaved classes to be placed in a library.  I'm sure there are other side effects as well.

So while I'm a little disappointed with how fragile and inflexible auto-mutation is, I can't point to any design decision and say "you made the wrong choice there" either.

[PJM_JKI]

---

@Daklu wrote:

Counter example:  If I take over a project that has lots of typedeffed clusters, I have no idea where in the application a specific cluster element is being written or read.  Suppose I want to find where the 'Name' field is used.  I can't do a search on an 'unbundle Name' node.  I have to find all the cluster's calling vis and manually search through the block diagram to see if that element is used.  With the common supercluster technique, you can bet it's going to be on the front panel of lots of vis.  Since I'm only interested in the Name element I'll spend a lot of time and brain power searching to find those few vis that use it.

Contrast that with a class.  If I want to find where the Name field is read I can simply search for instances of 'Get Name.vi.'  Easy.

---

About your counter example. Lets just assume that we are talking about good code (one using classes for every cluster and one not). It is always easy to find fault with poor coding practices (whether for or against using classes everywhere) and passing a "super cluster" in all your SubVI that just operate on only a sub section of it is poor practice.

So, in you counter example, let assume that we have a cluster call [line segment]. This cluster has two subclusters called [first point] and [second point]. Lets assume that this cluster is in a VI operating on it.

Now lets say that in your example the "name" equivalent will be a value for the [first point] subcluster.

If I want to find where name field (aka [first point]) is used, I can do a find all instance of the [first point] cluster and look at the code (or do a search for the text like you mentioned). This will work just fine. One advantage of having a cluster is that I can see what is in it and right from that VI where it seat; I have some idea of what this is all about. Additionally I know how to operate on cluster.

Now, lets look at the case where we use classes. The first cluster [line segment] is a class. The point are instances of another called [point].

So what do I see on my VI. A cube. Ok, so what data does that thing operate on? I guess I could put a probe on the bd to find out. That works (although since you got the data type in the probe this quickly get busy [too much noise]). Alternately, I could right click on the cube>>show Class Library. Great, now I look at the data for the [line segment] class and what do I see? Another cube. Need to repeat the operation to find the data of the [point] class. Now that I have that info, if I want to find out how to use this I have to figure out what data is public. Need to find the public method allowing me access to the data. This go on and on and on because I am learning to operate on a new data type. And I have to learn this for all the classes. This is more work.

This is essentially the reason why I consider all this effort to be justified when there is an overwhelming advantages using classes over not using them (otherwise I stick to good old cluster typedef).

I guess a lot of these difficulties are mostly LabVIEW limitations. There would need to be a lot of improvements made in the LabVIEW IDE before I would consider using classes for every cluster.

[JackDunaway]

---

@PJM_JKI wrote:

 There would need to be a lot of improvements made in the LabVIEW IDE before I would consider using classes for every cluster.

---

Can you elaborate on this?

[jgcode]

---

@Aristos Queue wrote:

And the reason is that any name change to the class resets the version to 1.0.0.0, because it is now a new class, and moving the class out of the library changes its qualified name, so moving it back in just changes the name again. You'd need the project to support Undo to undo that name change.

---

When I want to create reusable components of code, I will rename the Top Level Library (which is the namespace for the component) in NI Builder so that my src code does not conflict with the reusable distributed code. Changing namespace is common practice however, in this case I cannot reliably distribute this code (for internal components I can currently handle my own mutations) as the version get resets by NI Builder.

In reality, its really the same Class, it just needs to be renamespaced not reset.

Will the above ever be changed, or could it be an option in the Build Spec?

[tst]

---

@jgcode wrote:
Will the above ever be changed, or could it be an option in the Build Spec?

---

Try reading this thread - http://lavag.org/topic/12203-persisting-classes-and-geneology/

While it's possible that this could be changed for your specific use case, I assume that since this is a basic assumption about classes, it won't be changed.

[jgcode]

---

@tst wrote:

Try reading this thread - http://lavag.org/topic/12203-persisting-classes-and-geneology/

---

Thanks for the link, that answers all my questions.

Must have asleep when that thread was happening?

[Daklu]

---

Must have asleep when that thread was happening?

---

More likely partying.  

(We know all about you aussies...  😉  )