Downstream polymorphism example for Idea Exchange comment

[AristosQueue (NI)]

Can you differentiate for me the "functional sense" from the "oop sense"? Parents define functions. Children implement them. If the child adds a new function, it is not something that the parent has, by definition.

If you tag a parent class function as "Compute Result", then what is the child doing having a different "Compute Result"?

[Intaris]

It is adding to the result of the parent. Appending.

The child offers the results of the parent plus its own result.

[nathand]

Just wondering, is the root cause of this problem the way dynamic event registration works in LabVIEW? Seems like the right approach would be a child (in the OOP sense) that could register for its own events, and call the parent to register for events all the way up the chain - but, if I'm understanding correctly, the LabVIEW dynamic event registration model does not currently allow for this. Do you have a use case that doesn't involve user events?

[Intaris]

I only have the case i have and thats with userevents. Most other functionality can be kept properly encapsulated and thus doesnt raise the problem.  But its exactly the strictly typing of user events that i actualy want.  Therefore any approach which does aay with a strict typing of the api is inferiour inmy view.  Its exactly this encapsulated lvoop-strict boundary which gives rise to the idea.  Doing this without expanding the api is trivial.  A simple vi will do.  Its once the api is dependent on the class hierarchy that things get (imho) harder than they need be.

Maybe Theres a way to dynamicaly expand the event structure which would work but that avenue is unknown to me (aside from launching a load of asynchronous helper vis. These then dont tie in well with a single ui though.....).

An option is to do similarly to what you suggest with the child sending lvoop messages via events to expand on the functionality ala actors.  There are a few reasons i dont prefer this aproach. See above.

[AristosQueue (NI)]

Intaris: Please tell me more about the *generation* of these events.  Are you generating two different events? Or are you generating one event that has the parent class data bundled with the child class data?

[Intaris]

The events are for interacting with the objects, like calling methods of the object. They are not limited to simple data change actions. The events are literally the API of the class for outside interaction.  The base class defines some functionality (like "open FP", "close FP" and so on.  Children then add functions like perhaps "dock in subpanel" or "get FP image".

So think of the events as growing almost 1:1 with the methods of the classes. There are lots of individual events.

I also explicitly want to be able to interact at any level of the inheritance, like implementing a module handler, a preview manager and so on for different types of classes.

Maybe im just weird but i much prefer the idea of a strict API in this sense over a lvoop messaging API like the actor framework.

Shane.

[AristosQueue (NI)]

Not weird, but you're not the first to have these issues but you are the first (so far as I can find) to make this feature request, so I'm trying to distinguish whether you have stumbled into a great new idea or whether there's some existing strategy that would help you better.

So, make sure I have this right:

A parent class defines Open FP event. The caller fires the Open FP event to say "now it is time for you to open".

The child class defines "Dock In Subpanel". The caller fires the "Dock In Subpanel" event in order to open the panel AND dock it.

The caller knows that it is working with a child class instance. It could fire either event.

Going back to your original image from the Idea Exchange, what is the role of the "Get Mode" poly VI in this set up? Is it returning the Event refnum? And thus for "Open FP", it would return only one refnum for a parent class but two refnums for the child class?

[Intaris]

Regarding your summary of my "current" idea, you seem to have understood it correctly.  The communication is in real-life of course two-way meaning that the calling code can perhaps only listen to a subset of status changes of the object also.  Otherwise you've hit the nail on the head.

At this moment in time, given the discussions which have taken place since I made the original request and others which are still ongoing, I need to distance the current discussion from the original idea.

I am now the opinion that the original proposal was a huge hodgepodge of two completely distinct ideas which actually address two completely different problems but at the time seemed interrelated.  The two individual ideas both have im my mind (rather surprisingly 🙂 ) justification.

I more often than not need time (and discussions with others) to properly form my gut feelings as to how to solve observed or felt problems into real-world solutions to actual problems.  MY gut feelings I feel have merit but my expression of a) the actual problems and b) the proposed solution were both lacking.  Through discussions and blatant exploitation of your patience I have come to a more distilled and refined opinion.

So for peace of mind, I think it's important to completely ignore the original idea in this current context.

Spoiler

To further complicate things, I read a post on the LAVA forum about LVOOP UIs which made mention of the ability to actually register a callback VI for an Event dynamically, thus bypassing the static data structures I was having such trouble with in combination with inheritance.  I'm very unsure how this would fit in with my original idea of being able to expand my event-based API but it might just hold the missing clue to enable me to implement what I want using today's feature set.  This could essentially shift the event structure to a set of callback VI registrations WITHIN the object boundary, removing the original blockade to my idea.

I've yet to try to actually transform this idea into a proof of principle but somewhere in the dark recesses of my squidgy brain a flimmer of hope has been awoken.

[Intaris]

The other idea I was actually trying to approach was as follows:

I have a process which controls access to some resource (M300 in the original image).  This accepts a set (expandable) of message objects which are then used in conjunction with the resource to perform a specific task.  Due to "Preserve run-time class" the input object is correctly mirrorred on the output side.

Since the message objects have their own inheritance hierarchy, I was annoyed by the fact that changing the method object upstream of M300 caused the accessor VIs I had designed for the previous message object caused the polymorphic VI downstream of M300 to break the wire because the polymorphic VIs must have different names.  I was looking for a kind of "Dynamic Dispatch Polymorphic VI" to automatically update the polymorphic VI with my entire API when changing the upstream object type.

Using property nodes essentially allows this functionality.  The (kind of undocumented) ability to create submenus in propertynode hierarchies makes this essentially already implemented.  The further requirements I already outlined above were mistakenly thought to be an integral part of the idea, but it turned out they were actually distinct.

Spoiler

The main difference is that a polymorphic VI can have multiple inputs and outputs whereas a property node accessor cannot.