LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
cy...

Name-strict wire option

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined.

Good day forum. What do you think if the existing wire have an option to be 'strict by name'? Strict as in the wire itself will retain its name and passes only value to elements with the same name. I can see some possible use for clusters specifically, especially recursive ones. Thanks.

namestrictclusterwire.png

 

CY (expired CLAD)
4 Comments
RavensFan
Knight of NI

I don't see a use for it.  I can't think I've ever had a situation where I'd want to update one element's value in one situation, and a different element's value in a different situation.

AristosQueue (NI)
NI Employee (retired)

Like RavensFan said, I've never had a use case for this. If you have one, you should probably spell it out in the idea -- sometimes the particular proposal you make might not fly, but maybe there's a better idea we can brainstorm to the root problem. "I have an idea LV should let me do X action" doesn't work as well as "I have an idea that LV should let me accomplish Y goal somehow".

 

Even if I had a use case, there's a lot of downsides I see here...

 

Wire names are informal in LabVIEW 20xx anyway, so doing any language feature based on the wire names is pretty dicey. LabVIEW NXG has eliminated the concept of wire names from the language. I would not push for any feature that pushed LabVIEW 20xx away from LabVIEW NXG.

 

Bundle node has no error terminals... what happens if the name inside that variant doesn't match any element of the cluster? Silent fail?

 

Conversion to variant is inefficient. This feature seems like a messy mix of strong types and dynamic programming.

 

Overall, not going to get support from me.

cy...
Active Participant

@AQ: thanks for your feedback.

 

main reason on why this is proposed is due to the size of bundle by name. bundle by itself is decent in size, but it forces the creation of all terminals. given the scenario from Shift Register - Retain value if unwired (right terminal), one way we can improve on the state machine clutter is through the use of clusters. if the state machine has only a pair of shift register that bundled all the other shift registers, and allowing the overwriting of bundled elements without full wiring of the bundle function, that would significantly reduce the clutter, it would have behaved exactly like the specialized tunnels discussed in the shift register topic.

 

and about the variant thingy, I don't really meant it as a variant (reason chosen simply because a variant can be data of any type), but rather a incomplete subset of the original cluster with name inheritance. one may consider adding a error terminal to it, as the idea can evolve over the course of the discussion. or simply put it as a broken arrow for name mismatch, like how the global variable does.

CY (expired CLAD)
Darren
Proven Zealot
Status changed to: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined.