I just noticed http://www.ni.com/documentation/en/labview/4.0/manual/new-behavior-changes/, and while only two lines long, this sounds like a substantial shift in NXG's design philosophy. I'm writing configuration tools internally for 2018 right now, and named data wires was a godsend for both minimizing mistakes on the end of both the developer and the user when making human readable files. Named wires (combined with the generic bundle/unbundle vis) allowed for a shared ground truth in property naming for both serialization and deserialization, enforcing consistency between JSON, INI, and database data. I was hoping to eventually port over my work to NXG in the coming years, but this makes it sound like all clusters will require names and definitions before bundling, which seems cumbersome and prone to mismatches if not every definition is updated in time. (ex. explicit cluster definitions may have names that are different or mismatched from the class property they are wired to, while the generic bundle takes its element names directly from the name of the class properties wired into them, meaning changes are also automatically propagated.)
I can see how removing names from data wires would make the design of NXG easier on the NI Staff, but what do we, the users, get out of this change? What mechanisms will we have to propagate important metadata like class property names programmatically to vis and modules, allowing us to better validate and manage our code?
I'm not happy with the loss of wire names and name/type propagation in clusters either. You might want to read this discussion: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Malleable-control-labels/idi-p/3782013?profile.langua...
I just noticed http://www.ni.com/documentation/en/labview/4.0/manual/new-behavior-changes/, and while only two lines long, this sounds like a substantial shift in NXG's design philosophy.
Here's the right link (without the comma):
And yes, we're crippled by this change.
Yeah drjdpowell, your JSON tools library has been a huge part of what I'm working on right now, so thank you for that. As to the discussion you linked, my solution was to make my .vim wrapper only accept clusters, as it's very easy to capture a name by inserting a generic bundle in the input.
But for those at NI who want a use case example of how this change impacts the workflow, I'll write it out in full:
I have a class and a "magic vi" that serializes and merges a cluster into a JSON object string. This makes serialization incredibly simple: I unbundle all the private properties I want to serialize, bundle them up with a generic bundle, which pulls all the type names inside, and send it off to the magic VI. The magic VI uses the names as property names for JSON serialization, and so now the JSON is a human readable reflection of the class.
Scenario A: I want to add a new property to the class and serialize it. Simple enough. My class is now wearing a snappy tie along with its 3 piece suit, and the JSON mirrors it. (As long as the tie can be represented as a number, string, or collection of the above types.)
Scenario B: I want to rename IO_Type to Module_Type, to better represent its function. Easy enough, I just rename it in the class definition, and everything automatically propagates. Heck, I don't even need to make changes to the displayed VI, it just magically now looks like this, and everything works:
Now, the new NXG paradigm. No generic bundle, no name propagation. To start, I'm completely out of luck programmatically getting private class property names, as those are, well, private. Fine, I guess I'll manually define the cluster of data I want to store. The cluster definition gives the programmer a new freedom! The JSON property name doesn't have to match the class property name! Those exclamation points are used sarcastically, because nothing good comes from decoupling mirrored representations. Giving the person in a mirror newfound independence isn't a bullet point in a cool new programming paradigm, it's the first act in a horror movie that ends up being a thinly veiled allegory for outsourcing. Let's hope to god I don't miss any typos while creating it.
(Did you catch the typo? If this was a typedef, you wouldn't even be able to see it.)
Scenario A: adding a new property. Easy enough, but now there's another step because you also have to modify the cluster definition. We've given the class a new tie, but now we have to reach into the mirror world and give the mirror class a new tie as well. The mirror class thanks us, flashing a smile that makes you really hope it's not holding a knife.
Scenario B: This is where it gets tricky. Now when I tell you to "rename IO_Type to Module_Type", there's two places where it needs to be changed. Perhaps one might lazily think of only changing the cluster definition, after all that's where humans read it, and the change was done for the sake of readability. Good job, now the mirror class living inside your JSON is *definitely* holding a knife, as its subtle differences give it delusions of grandeur, "I am the most easy to understand and most familiar to the users, so I should occupy the representation of the class inside people's minds!" You weep as your ticket list and bug counts grow from the collateral damage of these two warring representations trying to annihilate each other like Jet Li in The One. Your relationship is strained as you spend more and more hours at work trying to overcome this avalanche of self-inflicted tech support. You manage to repair things with your partner by sacrificing sleep, and one night in the muddled fog that is your brain, you look in the mirror, and the you in the mirror looks back, and it winks.
Anyways, here's what that would look like.