Bundle output updates Typedef

[Intaris]

Whend ealing with buldled data structures, we're always told that creating Typedefs is a good idea.  It's just a shame that it's a PITA to maintain them sometimes.

Take a User-event API I have for one of my modules.  At the moment I have bundled my events (some sub-clusters of which are (or should be ;)) Typedefs themselves.

If I change the bundle at position 1, I have to do this updating routine once, twice at location 2 and three times at location 3 to properly update the ouput cluster typedef.

If we could link the output of the bundles (of each step of this clustersaurus) then the output data will be automatically updated to reflect our coding changes, which cuts out all of the manual updating.  The following illustration shows only the last bundle with the option activated (Autoupdate Typdef).

Why can't we designate the OUTPUT of the bundle to define the typedef.  Link the bundle to the typedef control so that whenever the datatype output of the bundle changes, the typedef is automatically changed also.  Event API programming would get SO much easier with this.

While the graphic shown seems to imply that the input terminal to the bundle is somehow important to the operation, it is not intended that way.

[Intaris]

I actually think that the input to the Bundle primitive needs to be prevented in this case in order to prevent broken wires.....

[fabric]

Bundle by name?

[Intaris]

Bundle by name?  I don't understand how that is related to what I just proposed.....

[fabric]

Just suggesting a solution to your specific problem: That modifying the top-level typedef requires a cascade of BD re-wirings... or did I misinterpret something?

Of course the example you posted is just an example and possibly shouldn't be commented on directly, but if all your bundles were "by name" then the updating routine goes away... doesn't it?

Back to your actual idea: Interesting concept. How would it work if the same typedef is auto-bundled in multiple places? Limit of one-per-customer perhaps?

[Intaris]

It's the other way around where the change is propagated from the code TO the typedef.

The update problem is when the code going TO the bundle changes (and I want these changes to be mirrored in the resulting Typedef) that this idea would save a lot of work.  I don't know how others do things but I generally create a typedef with my API events present which then inevitable at some point in time (often several points in time) needs to be updated to include new events.  By far the easiest way to do this is starting with the code for the event and then propagating the changes TOWARDS the Typedef.

My idea wants to make this propagation automatic if the option is selected.

The problem of multiple bundles in different places is interesting and one I hadn't considered yet.

[AristosQueue (NI)]

> The problem of multiple bundles in different places is interesting and one I hadn't considered yet.

I know of very few clustersauruses that are bundled in only one place. More commonly, I see them bundled in *every* place possible. 😉

But perhaps some sort of popup on the bundle node for "push changes back to typedef"? This would *only* work with the Bundle node since I don't have a clue how the Bundle By Name could ever figure out which items to replace vs which to add vs which to replace and rename. And since I would strongly advise not using the Bundle node ever with these sorts of data structures (favoring the Bundle By Name since it handles changes to the typedef much more gracefully), that's going to limit its utility.

That's the only idea for solving this that I've got this morning. Maybe something will occur to me later.

[Intaris]

@AQ I don't see how the use of Bundle by Name solves the problem at all.  My problem is lack of propagation in the other direction.
I find myself needing to implement code for Events in order to reliably get the data structures I require.  Manually editing the Typedef if frought with errors (Numeric representations / enums etc.).  As such I actually generate the new cluster datatype at the "Bundle" node (Certainly NOT "Bundle by name") BEFORE creating my typedef to match.  I then update my typedef using a dummy control I create from the output of my Bundle node.

Maybe I'm simply approaching the problem in completely the wrong way (Wouldn't be the first time) but I fail to see why such a simple task remains such an awful nuisance.  And yes, I know that defining the cluster before coding is all good and well but changes are paractically unavoidable and it's handling these changes which irks me.

---

And since I would strongly advise not using the Bundle node ever with these sorts of data structures (favoring the Bundle By Name since it handles changes to the typedef much more gracefully), that's going to limit its utility.

---

I have the exact opposite opinion to this statement.  It's exactly this use case I'm pleading for where I have a "Bundle" CREATING and DEFINING my Typedef which is then propagated throughout my code.  Here "Bundle By Name" is completely useless since it REQUIRES that my goal has already been reached to be of any use (Creation of the new Typedef).  It's the work involved in getting from my now insufficient Typedef to this new super-duper, never again to be changed (until next time) Typedef that I'm concerned with.  In short I don't want the "Bundle" to HANDLE the changes to the Typedef, I want it to MAKE the changes.

Please note that the "Typedef" mark on the lower of my two pictures is NOT on the input to the Bundle node but rather on the output.  Please ignore the constant wired to the middle of the "Bundle" node, it's very misleading unfortunately.  It shouldn't be there at all really.

[AristosQueue (NI)]

> @AQ I don't see how the use of Bundle by Name solves the problem at all.

It doesn't solve your problem. I didn't say that it did. What I said was that I could propose a solution that would work only with the Bundle node, but I never use the Bundle node and generally advise people against using it, so I considered the solution something of a deadend. I was hoping someone might figure a way to make it viable for Bundle By Name.

You want to use Bundle to define the type, but after you've done that, I want it replaced with a Bundle By Name for any of the changes that come the *other* direction (i.e. by changing the typedef first). The rub is that Bundle can be made to work fine for pushing changes up but poorly for pulling changes down.

[Intaris]

My use case is pushing changes up.

My previous question remains unanswered (Perhaps the answer is so obvious to others but not me that nobody's answered).  In the other use case (pulling changes down) with copious amounts of user events, how does one go about efficiently changing the Typedef so that this option becomes viable.  The reason for my idea is because I'm aware of no efficient way of achieving this "pulling down" approach for more complex datatypes like user event references (Or registered references to notifiers and such).

[AristosQueue (NI)]

But you do make modifications to the typedef directly on the typedef from time to time, right? The node on the diagram has to be able to pull down those changes. So rather than add a new feature that allows for push up on a pair of currently near-useless nodes, I'm wondering if there's any way to enable push up on the pair of nodes that already handle pull down so that we end up with one pair of nodes that do both.

As for "efficiency", it depends upon your view... for me, creating a constant on a terminal that already has the type that I need and then copy-pasting that constant directly onto the panel of my typedef is very efficient. I don't really seek an independent way to build those types because I want them to match exactly what I'll need on the diagram where I will use them.