Static Dispatch methods and DVR Refnums

[mje]

I've been working with data value references of classes quite a bit over the last few weeks. One feature I've fallen in love with is the new property definition folders for classes that the 2010 IDE allows us to use. Not sure how many of you are aware, but in addition to allowing easy access to several bits of data from a single node, they also automagically handle locking/releasing of class DVRs as well:

Which is completely awesome, by the way. Kudos for adding that feature.

Which got me thinking, it would be neat if statically dispatched methods could also do it. Currently for methods I might need to access from both a by-value and a by-reference scope, I find myself writing two methods: the by-value one which has all the logic, and a thin by-reference wrapper which simply calls the by-value method from within an IPE structure. I've love it if the NI wizards could find a way to have this happen automatically, kind of like the property nodes.

The only problem I see is how is LV to know when to be able to allow the use of this automatic dereferencing? There would likely need to be a requirement of having both an input and output for the class of interest, but other things creep up to, such as methods which have both in and outs for multiple classes. This might require a new type of connector flag separate from the four currently used (Dynamic, Required, Recommended, Optional)?

Any thoughts on this?

[Djed]

The only problem I see is how is LV to know when to be able to allow the use of this automatic dereferencing? There would likely need to be a requirement of having both an input and output for the class of interest, but other things creep up to, such as methods which have both in and outs for multiple classes. This might require a new type of connector flag separate from the four currently used (Dynamic, Required, Recommended, Optional)?

Any thoughts on this?

Yes, for automatic dereferencing you need at the very least an input/output pairing of VI terminals where runtime type is preserved, like in dynamic dispatch VIs. We have talked before about having an "in/out" or "inplace" marker on the connector pane. The real problem with this feature however would be error handling. When you dereference a reference (DVR or any other type), you can run into errors (the reference could be closed or was never good, etc.). You will notice that most nodes that take in references also have an error out terminal. Dereferencing a DVR can definitely produce errors (not to mention the fact that the access is asynchronous potentially and this would be hidden from the user) but static methods have no error terminals. There would be no way for us to pass errors along either to the static method itself nor to the callee; instead of getting the actual class, they could get a default data instantiation of the class and be none the wiser. This is why the property nodes will auto dereference; they have error out terminals.

[mje]

You will notice that most nodes that take in references also have an error out terminal. Dereferencing a DVR can definitely produce errors (not to mention the fact that the access is asynchronous potentially and this would be hidden from the user) but static methods have no error terminals. There would be no way for us to pass errors along either to the static method itself nor to the callee; instead of getting the actual class, they could get a default data instantiation of the class and be none the wiser. This is why the property nodes will auto dereference; they have error out terminals.

Yes, I suppose that if this ever were to see the light of day, some connector pane requirements would have to be enforced, not like those for the VIs in property definition folders.

I'm curious, in the case of property nodes operating on class DVR refnums, are the errors that can be produced (not counting the ones the VIs themselves might throw) the same as those that might be generated through an explicit in-place element structure? Also, I'm curious if using property nodes on simple by-value class wires (not refnums), can any errors be generated at all (other than any that are generated explicitly by the underlying methods)?

[Djed]

I'm curious, in the case of property nodes operating on class DVR refnums, are the errors that can be produced (not counting the ones the VIs themselves might throw) the same as those that might be generated through an explicit in-place element structure? Also, I'm curious if using property nodes on simple by-value class wires (not refnums), can any errors be generated at all (other than any that are generated explicitly by the underlying methods)?

I believe the answers to your questions are Yes and No, respectively. Under the hood, I believe the property node is decomposed into an actual in-place element structure. Property Nodes for by-value class wires I believe are decomposed into standard method calls and so would generate no additional errors. I'll forward this to the developer to see if he has any comments.

[Mr Mike]

Yes, I suppose that if this ever were to see the light of day, some connector pane requirements would have to be enforced, not like those for the VIs in property definition folders.

I'm curious, in the case of property nodes operating on class DVR refnums, are the errors that can be produced (not counting the ones the VIs themselves might throw) the same as those that might be generated through an explicit in-place element structure? Also, I'm curious if using property nodes on simple by-value class wires (not refnums), can any errors be generated at all (other than any that are generated explicitly by the underlying methods)?

I believe the answers to your questions are Yes and No, respectively. Under the hood, I believe the property node is decomposed into an actual in-place element structure. Property Nodes for by-value class wires I believe are decomposed into standard method calls and so would generate no additional errors. I'll forward this to the developer to see if he has any comments.

Djed is correct on both counts: property nodes by value are decomposed into standard method calls (with some error handling code to mimic property node error handling behavior). DVRs to classes have the same decomposition but the decomposed code is then placed inside an in place element structure. The error out on the DVR read on the IPES border is merged with the error input to the property node. The errors are passed into a merge errors node. You can see how it works in the image below.

- Mike

P.S. I'm glad you like the feature

[mje]

Sweet. Thank you both for clarifying that.

-m