Leaderboard

Have you heard that joke about UDP? You might not get it... (But seriously; just subscribing here for the emails out of interest on this topic)

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.

For references and more information, see worrydream.com/dbx Presented at Dropbox's DBX conference on July 9, 2013. Bret Victor -- worrydream.com http://vimeo.com/71278954

Also try this link: ftp://ftp.ni.com/support/softlib/labview/labview_development_system/ It also contains older versions.

Hi, see ftp://ftp.ni.com/evaluation/labview/ekit/other/downloader/ and just search for "LV2009SP1" (You're lucky, I could only find LV2009 and newer)

A) No, there's no mechanism for forcing the use of property accessors within a class. As Mikael points out, that's a sign of a class that has grown beyond its mandate if you're having problems with that. It's usually pretty trivial to make either a conscious decision to use the accessors internally or not. Commonly, multiple methods all need direct access to the fields, using IPE structures to modify values, so such a restriction would have limited use. B) The property node mechanism is nothing more than syntactic sugar around the subVIs. Since I eliminate the error terminals from my property accessors these days, the property node syntax isn't even an option for me -- the dataflow advantages (not forcing fake serialization of operations that don't need serialization) are obvious... the memory benefits of not having error clusters are *massive* (many many cases of data copies can be eliminated when the data accessors are unconditional). I've been trying to broadcast that far and wide ... it isn't that property nodes are slow or getting slow. It's that the LV compiler is getting lots smarter about optimizing unconditional code, which means that if you can eliminate the error cluster check around the property access LV can often eliminate data copies. This gets even more optimized in LV 2013. That means creating data accessor VIs that do not have error clusters, which rules out the property node syntax.

Quick test shows that stacking the property nodes has the effect of putting all of the calls inside the in place structure so all calls are atomic. Attached is the test code in 2012 if your curious. Just flip the disable structure to see the different effects. Test OOP DVR Properties.zip