Refactor: Move these VIs out of their classes

[neilpate]

In Classes Initialization.vi there are a bunch of VIs that take in the core cluster. Some are member VIs of classes, some not. See the example with the Ants class.

I think this code should be gently refactored so that the inner classes do not know anything about the core cluster.

Either these VIs should be removed from the classes, and put into the main library, or rather they should just return an instance of their own class with the data they need to initialise them passed in, so kinda like a constructor.

[neilpate]

Put another way, if the VI has the banner other than the main library I would not expect it to take in the core cluster.

[crossrulz]

I would avoid this terminology as most of that code is not in the library (yet). But I understand what you are getting at.

[crossrulz]

I think this code should be gently refactored so that the inner classes do not know anything about the core cluster.

100%. I am for almost anything that will reduce what gets touched by having the global cluster updated.

Without doing any dives, I would lean into having the Constructor and pass in only what is required. It feels more natural to me.

[neilpate]

I would keep the VIs, but change them to pass in just what is needed and pass out the instance of the class. In the calling code we could then bundle the objects back together.

[crossrulz]

Would the plan be to fix the constructors or pick a class and refactor it, including everywhere it is used?

I have my eyes on the Fake2DArray class as I think that should be broken up by having 2 child classes.

[neilpate]

Would prefer (as a general rule) to keep the individual PRs small, so this would just fix the constructors as a first pass. This will allow me to get familiar with what the classes are doing also.

A separate issue/feature would be refactor what the actual classes are doing.

[crossrulz]

I'm just making a comment to keep this discussion alive. It is something that should be done. However, main focus at the moment needs to be testing and getting things to a place where a release is actually shipped in LabVIEW (goal is 2026 Q1). Once we get over that hump, we can have a lot more confidence we didn't break things in future refactoring efforts.