09-27-2021 02:20 PM - edited 09-27-2021 02:21 PM
I have a class which inherits (Blue) an interface (Purple) which inherits an interface (Orange). Orange has a method "Do.vi" which Purple overrides (Blue does not implement this method).
I want to call this method, passing in Blue. My expectation is that it it should dispatch to the "nearest" implementation, ie Purple. However, I am seeing that it is skipping Purple and going straight to Orange.
Whats more, when I try to specifically upcast to Purple and yet it still dispatches to Orange at runtime
Am I wrong to assume that it should dispatch to the "closest" child implementation?
Example code attached (LV2020, reproduced in 2021)
Solved! Go to Solution.
09-27-2021 03:44 PM
I don't have 2020 to try it out but I believe this is because Green inherits from Orange as well. If you were to remove Green's inheritance from Orange, then it should work as you expect. I think this is because Green has a "virtual" Do.vi instance, i.e. it refers it to Orange, and the system can't tell which of either Green or Purple to call since both can call it, so it calls Orange because there's only the one instance of it.
I would also note that the upcasting there doesn't actually do anything other than change the color of the wire on the diagram. Part of the core LVOOP design (and OOP design in general) is that you can never just "change" from one class to another.
09-27-2021 03:54 PM
09-27-2021 03:54 PM
FYI If you haven't read it, this is an interesting resource into the decision making behind the behavior.
01-23-2022 10:14 AM
There's one more bit I want to add in case someone else stumbles across this answer in the future: LabVIEW interfaces can't override classes. Interfaces can't inherit classes and, the part that matters here, inheriting a class and an interface always gives the class priority.
Since (Green) is a class, its "path" to the vi becomes the active one, and the parallel interface override is ignored even though (Green) itself doesn't actually implement the vi.
This is an interesting implication I hadn't considered, but it makes sense based on the rules laid out in the Behind the Decisions on Interfaces (whatever it's called) document linked above.