A quick follow-up for now:
The GOOP2 to GOOP3 conversion tool left a few things in an incorrect state. All things I could correct most likely. It failed to notice one parent-child relationship in the class hierarchy. Also some of the NEW methods were not executable but I didn’t dig in to figure out exactly why.
However, the software framework I am porting relied upon some other tricky LabVIEW techniques, some of which also won’t port cleanly. So I’m porting it using a “clean room†approach making new classes in GOOP4 and repackaging the existing code. Also making some new design decisions to try to encapsulate the tricky bits better.
Specifically, the framework used Call By Reference pretty extensively. The VIs which were called in this way were GOOP2 class members. This doesn’t seem possible in LV OOP because you must use a strict type definition when loading and calling the VI. I tried doing the same thing where the type def. was to the base class method but actually trying to load and run a derived-class member. Unsurprisingly this did not work. Instead I’m channeling all those calls through a dispatcher method declared in the base class and implemented in the derived.
It also makes heavy use of DataSockets for inter-module communication. I’m going to try to retain that capability but encapsulate it behind a Publisher/Subscriber interface so that I can try other techniques without affecting the rest of the library.
Once I get the framework ported, it’s going to be a ton of work porting the actual applications, but it should be pretty cookbook and maybe I can partially automate it. Deadline's still a month away!
I will show my work once I get further along. This will look very familiar to at least one member here. (Hi Mike!)