> I think it would be pretty tricky to let LabVIEW decide
> what is by ref or by wire.
LabVIEW wouldn't decide. It would simply evaluate "refnum data type or not". If it isn't a refnum type, it wouldn't be a reference. No DAQ tags, no string IDs, no int indexes -- in my imaginings, you'd be required to continue treating those as by-value types and wire them as you do today, because the alternative is waaaaay too wacky, and there's no profit (in the NI sense) in building a whole new metatyping system (i.e. a way to say "this typedef of an int should be considered a global reference) just to enable structure jumping. Letting LV make a decision about types that is have defined behaviors is fine, in general. My hesitation is about this specific case and the private data exposure.
> If those tunnels would not require wiring, I'd say the
> height should be automatically linked.
That approach was explicitly evaluated and rejected by the feature design team when designing linked tunnels. The spec document records the feature alternatives that were considered and rejected. The reasons for rejection listed are:
An alternative visual indicator would be needed to account for the absence of a drawn wire between terminals [minimal space available on a tunnel, strong pushback against making the tunnels bigger].
Drawback of not having a physical wire connecting the two associated tunnels caused this feature alternative to be rejected. [Readability value of wires discussed elsewhere in the spec.]
[If we draw the wire, there's no need for the tunnel alignment, and many use cases prefer unaligned tunnels (see user complaints about kinks that occur with shift registers on nodes like Build Array or Add).]
The parts in [] are where I am extracting and summarizing from other parts of the spec document.
Basically, forcing the left and right tunnels to be same height puts annoying wire kinks in many wires, the visible wire makes the connection obvious and avoids the need for a custom glyph, and the wire is nice anyway for readability, so R&D did that. 🙂
If the linked tunnel feature only works for by ref classes, I won't be able to use it. I'm not sure if that's what you're saying.
I avoid by ref objects if I can. If I can't I usually have a interface parent and the by ref as a child, containing a by wire sibling. All code would use the parent, so I can switch between by wire and by ref.
If it would only work for by ref objects, what is the point? Might as well just use the input, tunnel, and not wire the output tunnel at all. Like I did in the top wire.
I don't really see why such a link would be a problem for normal objects. It would work exactly the same when the object is not used in the case, it's just that the wire would be 'invisible' (a, b). If the input tunnel is used, a copy might be needed if the wire isn't wired to the output (d, e). But that could be intentional and the same thing happens (potentially) for every wire that is split (d). If the wire is wired to the output, it's the same as without the fancy linkage (a and c, regardless if it's used or not).
>My hesitation is about this specific case and the private data exposure.
Do you mean implementation hiding? The data isn't exposed, but the implementation is (partially exposed). I'd by worried about that. Especially when it changes, and all code breaks because peaches expect a by ref... That would be bad. The implementation should be encapsulated, and should be nobodies business. Then again, in a way it's already exposed a little, as by ref can be treated differently then by wire (that's in fact why we use them).
An alternative visual indicator would be needed to account for the absence of a drawn wire between terminals [minimal space available on a tunnel, strong pushback against making the tunnels bigger].
Drawback of not having a physical wire connecting the two associated tunnels caused this feature alternative to be rejected. [Readability value of wires discussed elsewhere in the spec.]
[If we draw the wire, there's no need for the tunnel alignment, and many use cases prefer unaligned tunnels (see user complaints about kinks that occur with shift registers on nodes like Build Array or Add).]
Seems a bit of a circular reasoning to me.
The first one isn't really a reason, more an observation. A visual indicator won't need to be big if the heights are linked.
The middle one I don't get at all. The ' drawback' is not mentioned, and I assume it's only a drawback because the heights are not aligned.
The last one I agree with, for linked tunnels as they are. Those don't need to be aligned (even though I do usually do it). But their linkage isn't related to the data flow, that's what the wires are for. Because the wires show the data flow, the alignment isn't needed.
> If the linked tunnel feature only works for by ref classes, I won't be able to use it. I'm not sure if that's what you're saying.
For raw refnums (any type), for clusters and arrays that exclusively contain refnums, and for classes whose private data (all the way up the inheritance chain) exclusively contain refnums, or for clusters/arrays/classes that contain additional clusters/arrays/classes that exclusively contain refnums.
AND... hah! I just realized why it can't work for classes at all... there's no way to guarantee that all *descendants* (including those not yet in memory!) only contain refnums.
>> A visual indicator won't need to be big if the heights are linked.
>Incorrect. Two tunnels can be aligned today and not be linked.
But it wouldn't take a big visual indicator to show the difference.
If the heights are not aligned, it would take an ID or something in the tunnel graphics, making it big. If the heights are aligned, it would just require a small indication to show it's a new fancy linked tunnel.
> But it wouldn't take a big visual indicator to show the difference.
The contention of the design team was that anything that could be done within the space of a tunnel was insufficient. The tiny triangle that is drawn today to indicate that a linkage exists was deemed too easy to miss, and there's not much room for more in there. Anything done on the outside started to not look like a tunnel.
This is a subjective decision, and you may not agree. I'm just relaying what the consensus was the last time this was investigated.
NXG has more space for such annotations -- their base terminal size is larger. Might be worth revisiting there.
