LabVIEW
Refactoring LVOOP
@bdiesel wrote:
surely there needs to be a capability to aggregate common properties and methods in to a common ancestor without having to rewrite/generate all of them?
There really isn't an automated way to do that (at least not without add-ons).
After I got used to how LV handles classes, I do not have any problems with it. LV could use more features to move methods around for sure...
If you have a concrete capability\feature (more concrete then "refactoring is hard, make it easier"), you could post it on the idea exchange.
If this feels like a problem with OO, imagine the mess without OO...
Search LabVIEW like a graph!
@bdiesel wrote:
wiebe@CARYA wrote:If you have a concrete capability\feature (more concrete then "refactoring is hard, make it easier"), you could post it on the idea exchange..
I felt that:
"capability to aggregate common properties and methods in to a common ancestor without having to rewrite/generate all of them"
was a reasonably concrete feature?
There are a lot of ifs and buts How exactly would this be triggered (where do you click)? The parent already has the VI. There is code in it, is it replaced? By a child method? Which child? What happens to the other child's methods? And so on. I think in your situation all of these questions have reasonable answers, but do they scale to all situations?
A solution that works in trivial situations might turn into an auto-destruction feature for more difficult situations (like the diagram clean up
).
There have been related posts about moving private data to parents, and how that is prone to errors if it's not removed from child private data. But I don't see how that process could be automated.
I'd like some functions to move a VI (method) to it's parent (instead of remove\rename\add\replace inputs and outputs). I think some add-ons facilitate that, but I don't use them.
The closest i can think of is cloning a class with the data you want in the parent and set it as parent. There are functions for that in G# (cloning classes and cloning methods between classes and change inhertitance) and it should work with native classes also to alleviate some pain, but yes, refactoring can create a whole bunch of issues to untangle until it works.
/Y
wrote:
@bdiesel wrote:
wiebe@CARYA wrote:If you have a concrete capability\feature (more concrete then "refactoring is hard, make it easier"), you could post it on the idea exchange..
I felt that:
"capability to aggregate common properties and methods in to a common ancestor without having to rewrite/generate all of them"
was a reasonably concrete feature?
There are a lot of ifs and buts How exactly would this be triggered (where do you click)? The parent already has the VI. There is code in it, is it replaced? By a child method? Which child? What happens to the other child's methods? And so on. I think in your situation all of these questions have reasonable answers, but do they scale to all situations?
A solution that works in trivial situations might turn into an auto-destruction feature for more difficult situations (like the diagram clean up
There have been related posts about moving private data to parents, and how that is prone to errors if it's not removed from child private data. But I don't see how that process could be automated.
I'd like some functions to move a VI (method) to it's parent (instead of remove\rename\add\replace inputs and outputs). I think some add-ons facilitate that, but I don't use them.
I'l investigate the add-ons. Manual methods are error prone and time consuming. Which means refactoring tends to be delayed until it becomes absolutely unavoidable.
wrote:Manual methods are error prone and time consuming.
Both problems disappear when you done it for the 100th time 
.
I agree thinks could be done to make it easier. Not sure why it's not happening. I like to stick to plain LabVIEW, no add-ons, simply because I can't depend on their presence on all machines I use.
If I needed something like this repeatedly, I'd make a script VI to do it. But promoting scripts that moves some stuff like I want it to, to build-in features is not likely to happen. Naming the menu item is just one of the problems ("Right-click>Advanced>Aggregate Common Properties And Methods In To A Common Ancestor" won't make it). Explaining what it should do is exactly is another. Finding consensus about what it should do exactly another.
Some basic tool additions would go a long way. For instance, we can create an overwrite method in a child. Why is there no option to create a base method in a parent (copied from a selected child)? That would help in your situation, but it's only one step.
Moving private data from several childs to the parent will be very tricky. I don't think I'd like LabVIEW to do that. What happens to unbundles in the child methods? Replace them with VI's? What if in placement structures are used? The VI's have error handling. Should it be used? The clusters didn't... It will create a mess.
