Leaderboard

No one at NI can edit those pages -- would be a conflict of interest under Wikipedia rules. Please update the entry if you believe it can be approved. And, while we're on the subject, everyone please consider adding a recurring donation to Wikipedia. They now have set up $3/month recurring donations, which makes it easy to support one of the most valuable databases on the planet.

Ah, the "double dispatch to compare heterogenous types" problem. An ancient frustration of software developers everywhere. And, worse, I suppose you want the comparison operation to be commutative too (i.e., it doesn't matter which object you put into the top input and which into the bottom input)? a) read this: http://en.wikipedia.org/wiki/Double_dispatchhttp://en.wikipedia.org/wiki/Double_dispatch b) I have never heard of a good solution to this problem in any computer language, but LabVIEW is worse than most because of some limitations on our features -- such as the inability to type cast a VI refnum into any connector pane type *without* LabVIEW type checking it. That kind of "reckless type casting" is a damn fine way to crash any application, but if you can write a system that guarantees (and I mean system-level provable) that all the casts are safe, that's the key to a high performance, low maintenance implementation of such a comparison algorithm. But LabVIEW doesn't generally include "use at your own risk" nodes (the exceptions being Type Cast and Call Library, but even Type Cast has some restrictions which is why it doesn't work for this use case). Even if you had such reckless type casting for VI refnums, this is a hard problem to solve elegantly. I generally recommend that you do the type testing, and either have your own static dispatching through a multilayer maze of case structures or build a 2D dynamic dispatch table of your own. This has an obvious performance hit, even if you implement your own "Get Class Index.vi" that every class overrides to return a unique (but compact sequential over the whole set) integer. There is only pain and suffering down this road if you want to avoid runtime type checking. But it is possible. There are multiple ways to do it. All of them are bad in some way. The Visitor pattern is one you will become very familiar with if you try to do this... lots of variations on the Visitor pattern that all essentially go like this: You create a comparison object that visits the first object to be compared, collects some data then visits the second object and actually does the comparison. You can find endless variations online discussing this problem. One solution that does NOT involve the Visitor pattern is this one... If you know the total set of child classes that will ever exist, this works with high performance but high maintenance burden and lots of VIs: 1. In the ancestor class, create a method "Is Valid.vi" that is dynamic dispatch on the top input. 2. In the ancestor class, create N methods named "Is Valid Assuming First Input is <class name>.vi" where <class name> is the name of a child class. The top input is the child class type. The bottom input is the ancestor type and is dynamic dispatch. Do this for every child class that is not an abstract class. 3. Each child overrides "Is Valid.vi" and uses that VI to wrap a call to "Is Valid Assuming First Input is <class name>.vi", where <class name> is this child class' name. 4. Each child overrides ALL of the methods for "Is Valid Assuming First Input Is <class name>.vi" so that it's type is the bottom type and the other class is the top type. Here you write the actual comparison between these two objects because you now know the exact data type. Oh, but there's a problem... you don't have access to the private data of the other class. So you expose the necessary data accessors to dig into the other class. And you write the comparison. 5. But THEN you take that comparison and you do "Create SubVI From Selection" because you need that exact same comparison in the function on the other class where the top and bottom inputs are flipped. -- end -- This results in a system that is actually quite fast at runtime but is a pain to maintain -- the number of methods in the system expands *geometrically* with the number of concrete child classes. All of this gets even worse if you want to have plug-ins or dynamically loaded classes (the difference being with dynamically loaded classes, you know all the classes ahead of time but you don't want them in memory whereas with plug-ins you don't know the complete set when you write the framework). So far as I know, there is no elegant solution to this problem anywhere in CS. If you find one, please let the world know.

If anyone knows Norm, you know how much hand waving he does when he gets excited. Well, the Leap Motion got hand wave overload