Allow cluster type to propagate upstream to "bundle" primitive

[fabric]

In LabVIEW, data types generally propagate downstream. If you wire a cluster output into an "unbundle" node then the IDE lends a hand by resizing the unbundle node automatically. Nice.

I would like to see the same behaviour applied to the "bundle" node. In this case the type information needs to travel upstream. Yes, backwards!

Excuse the overly simplistic example... Yes, I know we could just connect the bundle node's middle terminal in this case, but it illustrates the concept.

A more realistic use case would be nested clusters or nested private data in a class. In this case propagating the type upstream could be quite handy when bundling various sub-clusters:

Note: There are not many situations where the IDE will allow a data type to propagate upstream, but there is already some precedent for this: In certain situations the "Variant to Data" function will automatically assume the type of the wire connected to its output.

[tst]

This has already been suggested - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Adaptive-quot-Bundle-by-name-quot-from-the-cluster-out...

I didn't vote for that idea, but I'll admit that this presentation is slightly more compelling. The problem is that I have an instinctual aversion to the idea, mainly for reasons of safety. The idea has some appeal, but I can't help but feel dirty when I imagine your example with a bundle by name. Like AQ said in the other thread, there's no techical reason why this can't be done, but somehow it feels like for the amount of cases where it would be useful, it's not worth the headaches.

And after having that whole discussion with myself, I will vote for both ideas, mainly so that NI can potentially look into it and see how it actually behaves if you implement something like this. The main attraction is in getting rid of cluster constants which are there just to supply type information.

[fabric]

---

@tst wrote:

This has already been suggested ...

---

 Thanks for pointing that idea out. I have given kudos there too.

...but I would also say that this is NOT quite a duplicate. 

There is one important difference:

• I would like to see type propagation to the "bundle" node, while the other idea refers only to "bundle by name". The intrinsic behaviour of these two nodes is very different.

When we connect a cluster wire to an "unbundle" then ALL elements are exposed. It can sometimes be very useful to know you are seeing all the elements, especially if the cluster content changes regularly throughout the development cycle.

In the same way, the main purpose of this idea is that ALL elements are exposed when wiring a "bundle" node's output. A nice side effect of this behaviour is that if items are added to the cluster definition later, then the code will break since those extra inputs will now be unwired. This would not be possible with "bundle by name" since it relies on manually growing/shrinking the node.

[Ironman99]

I kudoed this idea, and not the previous one, exactly for the reason explained by fabric. I only want this behaviour applied to "bundle", and not to "bundle by name". The "Bundle" node auto expands itself and always shows all its component, making obvious which of them are disconnected.

If "bundle by name" got its type "upstream", some not connected components could stay hidden, making not so easy to understand why the VI results broken. The programmer could be induced in the false assumption that hidden components should stay unchanged.

The latter situation could lead to some (broken) VIs like the following one, which gives no hints about what makes impossible to run it.

Cheers,

Marco.

[tst]

OK, that's a good enough reason to revoke my vote from the other idea and it does help clear up what my problem with it was - it lacks the explicit value of the wire going into the input terminal. Since I use BBN almost exclusively, I would definitely have a problem with that.

I'm not so sure about this one, now. I'll leave my vote on, since it's already there and unlike others, even if there are features I don't usually use, I don't think that means they shouldn't be improved, just because there are some cases where they can be useful.

[Albert.Geven]

I did not vote for this because I really believe in bundle by name.

[AristosQueue (NI)]

Like Albert, I also withhold my kudos from this idea specifically because it is for the plain Bundle node. I've had too much code break because of that node and strongly encourage the use of Bundle By Name instead (along with some basic operational rules for adjusting clusters). Use of the bundle node to create new clusters seems like a good idea. Use of a bundle node to populate existing cluster types (i.e. types coming from some other source) seems like a bad idea.

But... whether I kudos something or not is my own decision as a user of LabVIEW. Speaking as a developer in R&D, this is a totally doable idea, and if the community thinks it would help them write better G code, there's nothing that I can see technically standing in the way. As you can see in the other idea, someone did post an example of an existing node (Variant To Data) that has this "look downstream" behavior. Take a look at that node and see if you like the behavior and want it to become more common.

[fabric]

One thing that LV's syntax lacks is a way of enforcing that ALL elements in a cluster are written/initialised. Among other things, this idea was intended as a simple way of providing that functionality. Unfortunately "forced wiring of all inputs" is not possible with Bundle By Name, or (worse still) even by using the simple Bundle node with a type input.

There may be better ways to achieve this goal. Perhaps a right-click option on the node(s) to force wiring of all inputs?

[Intaris]

@fabric

using a simple bundle with a type input DOES ensure all elements are initialised.  It initialises everything to the value of whatever you connect as the Type.  Or am I missing something?

[fabric]

@Intaris

Not quite what I was referring to. Perhaps "initialising" was the wrong word... "setting a sensible value" might be a better description.

LV lacks a good way to enforce that all elements of a cluster are written with new values, and this is most commonly seen when adding elements to an existing cluster. IMO, this is the one big shortcoming of Bundle By Name.

A good example would be configuration settings (e.g. stored in class private data). Imagine I have a simple module with two settings "A" and "B", which I set to some nice values in an initialisation VI. Later on I add a new setting "C" to my cluster/class. Unfortunately I forget to set this value in my initialisation VI (because I am distracted, or stupid). This is a difficult mistake to catch.

From memory, the Bundle node used to break code if the type input was used and one of the inputs was unwired (so that worked for the "must bundle all" behaviour)... but now the Bundle node will happily allow an unwired input.