Understanding Preserve Run Time Class in an In-place Element Structure

[nileracecrew]

I am trying to understand the rules for swapping the objects that two DVRs refer to.  (There is also a longer conversation about this topic.)

Quoting this page: http://www.ni.com/white-paper/9386/en#toc3

You must maintain the type of reference at runtime, which means that you cannot exchange data values. With a new Preserve Run-Time Class.vi primitive, LabVIEW can guarantee runtime type consistency that you can use to swap two values.

From what I can tell, the only way the swap would fail is if, at runtime, the top DVR was carrying a parent object, but the bottom DVR was carrying a child object (or vice versa). In that case, the bottom PRTC would fail since a parent object is not of child type.

Question 1: Why is this prohibited? A parent DVR can refer to a child object at runtime, either when the DVR is created, or by injecting a child object using a PRTC. This makes sense since a child object is also of parent type. Why can't we swap it back to a parent object?

Later on in the same document, there is a suggested workaround if you want to be able to swap objects at different levels of the inheritance hierarchy:

If you need a class reference that lets you change the underlying object, create a reference to a cluster of the class. This gives you the ability to swap values at the cost of hierarchical casting.

I believe the suggestion is to wrap each object in a single member cluster, and make DVRs to those clusters, like this:

Then the objects can be swapped without PRTCs. This adds another level of plumbing when you initialize or dereference the DVR, and you lose the ability to directly cast the DVRs since they no longer refer to classes, but clusters.

Question 2: I understand why this works, but why is it necessary?

Thanks for any help.

[nathand]

I don't have a full answer, but in an effort to get a discussion started, let me suggest that the rules for an In-Place Element structure seem to be the same as the rules for a pair of dynamic dispatch inputs and outputs.  Does that help?

Also, have you read When Should the 'To More Specific' or 'Preserve Tun-Time Class' Primitives be Used with OOP in LabVI...

[nileracecrew]

---

@nathand wrote:

I don't have a full answer, but in an effort to get a discussion started, let me suggest that the rules for an In-Place Element structure seem to be the same as the rules for a pair of dynamic dispatch inputs and outputs.  Does that help?

Also, have you read When Should the 'To More Specific' or 'Preserve Tun-Time Class' Primitives be Used with OOP in LabVI...

---

This is a good observation. I had seen that article before, but the dynamic dispatch aspect had not sunk in.

My understanding (could be wrong) is that the requirement that all wires going to a dynamic dispatch output must come from the dynamic
dispatch input is to prevent object slicing. This is generally a good thing as most of the time object slicing is unintentional (particularly if you're using dynamic dispatch) and leads to nasty bugs.  

In that light, it does make some sense to treat the IPE terminals as dynamic dispatch. I'd argue that, compared to the dynamic dispatch VI case, it's more likely that you intended to modify the object's type, but most of the time it's still probably unintentional.