Autoadapting similar LVOOP methods without Dynamic Dispatch

[shoneill]

I have been experimenting with using polymorphic VIs with LVOOP.  In my specific case, I have a large-ish hierarchy of very similar classes.  Each one has a "Read" command.  I have a base class which defines SOME of the functionality, but the "Read" method is not defined here since each datatype implements its own "Read", one for SGL, one for I32, one for Boolean and so on.  As such, Dynamic Dispatch won't work (and I don't like Variants as inputs).

This works OK except for when I want to swap out a SGL datatype with an I32 and the VI "Read" becomes broken because there is no inheritance link between the SGL "Read" and the I32 "Read" even though the two might even have the exact same name.  Instead, I can create a Polymorphic VI with all "Read" variations in it (I can do this by scripting, it doesn't need to be manually maintained).  Creation of the POLY VI is actually relatively simple. Choose a specific version of the method (file dialog), parse up to the root ancestor, parse back all children which have the same tag and add them to a POLY VI.  To do this, I have added a line to the Description of the VIs involved (for example "<POLYOOP>Read</POLYOOP>".  Once created, I can simply drop this polymorphic VI instead of a naked "Read" and everything works fine.  Of course this means that all of my "Read" need to be static VIs because POLY VIs don't work with Dynamic Dispatch.  A small trick is reversing the order of the concrete instances found when adding to the poly VI so that the most specific are listed forst, followed by more generic with the base class as the LAST entry in the Poly VI.  This way, autoselection will choose the most specific version available according to the class type at the input.  If I need a different version, I can still right-click the VI and choose the specific version I want.

This can be used for allowing switching of methods (which may have different names AND different connector panes but which all represent the same action for an object).

• It allows for autoadaption of differently-named functions for two distinct classes irrespective of connector pane differences
• It requires a POLY VI to be maintained (Not part of any of the classes as this POLY VI can be project-specific) - automating the POLY VI creation alleviates most of this pain
• This operates on the visible wire type, not on the actual object type, so care is required to make sure the correct versions are actually being called (In my "Read" case, this is not a big problem)
• Creating arrays of varied objects will cause all to execute the method associated with the common denominator.  This approach is targetted more at cases where we pass a command to a handler and retrieve an object of the same type (by utilising "Preserve Run-Time Class at the output of the handler) and then want to access the returned data.
• Is there a way to do this without a POLY VI?  XNode?  UIsing the POLY VI pulls in a lot of classes as dependencies (All which have the <PolyOOP>Read<\PolyOOP> text).... Being able to do the adaptation dynamically would be cool.  I have no XNode experience but apparently XNodes and LVOOP don't mix too well?

Perhaps most importantly: Is this a completely off-the-wall and stupid idea?

[UnlikelyNomad]

It seems to me that you'd be more interested in a VI scripting topic to accomplish some automatic code generation but in general OOP itself wouldn't fit this. At the highest level there is knowledge of what the output type should be and therefore should be able to make assumptions about the code it should run to get that data. There are ways I can picture accomplishing this within OOP code but it would break nearly every prescribed design paradigm, be extremely complicated (lots of VIs), and difficult to debug.

Or use variants everywhere and some type of data reflection which will be a lot of extra code and completely break type safety.

I'm currently exploring some XNode implementations to simplify some boiler plate code for by-reference architectures but have hit a few road blocks on doing type reflection on the class from within the XNode; turns out different execution contexts makes it difficult to get references to classes from the project on top of XNodes already being difficult.

[shoneill]

I believe a LV version coming soon (but not very soon) will not address this directly but may give us tools to allow this kind of operation to be performed.

I'm hopeful.

[infinitenothing]

So, in a case like channel wires, they implement their end typing with a right click dialog (see below)

If you want it more automagical, you'll need a VIM with a type specialization structure (see second snip, requires lapdog) for specific types

 

[shoneill]

That's exactly what I was referring to, but apaprently there are additions coming which will make things even easier.......