Case Structure tunnel ownership hierarchy bug

[littlesphaeroid]

While working on an update to the BundleMagic plugin for LabVIEW, I discovered a subtle bug in the ownership hierarchy of tunnels on case structures. The selector tunnels have the class "Tunnel", while normal tunnels have the class "SelectorTunnel". See the attached screenshot. I'd be interested to know if this is a mistake, and what consequences it might have. If corrected, my plugin will break in the future when trying to present right-click menu options for those tunnels.

[raphschru]

Hi littlesphaeroid,

I think this is normal because "SelectorTunnel" means "tunnel of a structure that has a case selector" (so, not the case selector tunnel itself). This is the same logic as a "LoopTunnel" that means "tunnel of a loop structure".

I agree the class name is misleading for the case structure. Maybe "CaseTunnel" would have been better... Also the fact that the class "SelectorTunnel" has no specific properties / methods compared to its parent class "ConditionalTunnel" is quite weird too. In my opinion, class "SelectorTunnel" should not exist...

Classes "SelectorTunnel" / "ConditionalTunnel" offer additional properties such as "Linked Input Tunnel" and "Use Default if Unwired" (only output tunnels), and methods such as "Clear/Link Input Tunnel" (only output tunnels) and "Replace with Case Selector" (only input tunnels).

The actual case selector tunnel is "only" a Tunnel because it is always an input tunnel and it makes no sense to replace it by the case selector because it IS the case selector.

So, this may be a weird design choice, but I don't think this can be considered as a bug.

Regards,

Raphaël.

[littlesphaeroid]

Thanks Raphaël. I wonder if you didn't look at the image I attached. You can see that he selector tunnel is called "Tunnel", and the non-selector tunnel is called "Selector Tunnel". That really does appear to be backwards. 

[raphschru]

---

@littlesphaeroid wrote:

I wonder if you didn't look at the image I attached.

---

I sure did, and I explained why it looks like a bug, but actually it isn't.

Here is the same explanation stated differently:

Class "Tunnel" = generic tunnel that can't by nature have specific functionalities such as linked input / default if unwired / replace with case selector / auto-indexing / conditional terminal... The case selector tunnel is one those.

Class "SelectorTunnel" = tunnel of a structure that has a case selector (so, a tunnel of a case structure). It has specific functionalities such as linked input / default if unwired / replace with case selector. It concerns any tunnel of the case structure except the case selector tunnel.

Regards,

Raphaël.

[rolfk]

It sounds indeed backwards but makes in a weird way sense since a Case Tunnel is not the same as a Loop Tunnel. A Loop Tunnel has many extra options such as auto-indexing that would make little sense for a Case Tunnel. On the other hand “use default value if unwired” makes no sense for a Loop Tunnel. So there needs to be a distinction. The Case Selector on the other hand has no such options at all but other significant different options, so must be again a different class. All of them can be used as Tunnel although in the case of the Case Selector that is not so often used. Personally I’m on the fence about it, I like the compact look of using the Case Selector as tunnel instead of wiring the value through a separate tunnel, but feel unhappy about the situation where a real tunnel also could hide under the Case Selector. It makes the code less secure to read: Is this a different value wired through a tunnel under the Case Selector or is it the Case Selector value wired through?

Maybe it should be forbidden to have tunnels overlap!

[littlesphaeroid]

Thank you for the clarification! This helps.