Property Node Style Bundle and Unbundle Element

[SteveChandler]

Problem - Bundle by name causes unnecessary wire bends because the type specifier is on the top.

Make the type specifier terminal on the upper left and the output on the upper right. Also right clicking on an item will allow you to select "Change to Read" or "Change to Write".

Would look something like the following.

[AristosQueue (NI)]

> A passthrough could guarantee execution order, so there's a functional difference.

That functional difference actually could be a problem. It encourages serialization of operations that actually have no dataflow dependency upon each other. Falls under the same category as LV class data accessors that do read only -- I've suggested many times that we shouldn't generally have an "object out" terminal on such VIs.

If we ever tried to merge this with property nodes and LV class accessors, then this passthrough idea actually introduces another problem... those nodes can trigger errors on each property, and the properites below return default values. For these passthrough terminals, it would be ambiguous if they should return the default value of the property or truly pass through the data regardless of whether higher properties had an error.

As a LV R&D developer, the passthrough terminals are certainly do-able, and if they got enough kudos, we could swing it. As a LV user, I'm really not liking this ammendment to the idea. (To be clear, I do like the idea overall.)

[Darin.K]

First of all, I do not intend to hijack this idea, but how does the most innocuous addition elicit suggestions of hiding wires behind nodes and discussions of serialization and error triggering?

How does writing to a cluster generate a runtime error?  Beats me.  As to extending to PNs or accessors, there are clear choices, as long as said choice is documented, where is the ambiguity?  But that has very little to do with this idea, or my tweak.

Under the hood, this node would look like this:

You can choose to wire or not wire the inputs and the outputs.  There is actually no need to specify Read or Write.  All of the By Name business is just a way to map terminals to the right place on the Bundle or Unbundle Nodes.  (Why multiple bundles by name are permitted is a mystery to me).  If no inputs or no outputs are wired, the Bundle or Unbundle Node can be dropped.  My point is that regardless of what shows on the BD, those terminals are there just begging to be used.  All elements can be read only, write only, or read/write determined simply by what is wired to them.

If a particular LV user likes to hide or branch wires that is still their choice.  I say when making a purely cosmetic change, why go half way?  It works great with the CLFN, why not here?

Thus endeth my distraction.

[AristosQueue (NI)]

> First of all, I do not intend to hijack this idea, but how does the most

> innocuous addition elicit suggestions of hiding wires behind nodes and

> discussions of serialization and error triggering?

You suggested an in/out terminal. There are two ways to get that: either a single terminal on the node or a pair of terminals on the node.

If the wire connects to the node at a single point, then it is exactly equivalent to today's diagrams where you attach to the node and then continue the wire behind the node.I know that's not something people like, so it is worth discussing how to make it visually more pleasing. It also would need some way to show that the node is not affecting the dataflow order, despite the wire appearing to pass through the node.

If it is actually two terminals, one in and one out, that means that the node is now in the dataflow for the written data. That creates a change to the actual execution of the program. You said this is supposed to be a purely cosmetic change. Changing the dataflow order is not a purely cosmetic change.

The idea itself talks about making bundle/unbundle more like property nodes. Property nodes do not have read/write terminals. Every property is either a read or a write. If we add in/out terminals to the bundle/unbundle nodes then, presumably, that is something that should be added to the property nodes (the original idea implies a desire for consistent notation across these things). However, actual property nodes have to handle errors, and that raises an ambiguous case.

And that's how an innocuous ammendment becomes a larger issue.

[Darin.K]

Perhaps I am not expressing myself clearly here. I have rolled my own Node which selects read and or write based on what is wired to an element. It works great and was pretty easy to do. It really cleans up the wiring in many cases. My personal bias is that hiding wires is a big no no and does not play nice with BD cleanup or VI analyzer. By purely cosmetic I simply meant that instead of having a write element followed by a read, or a branch and wrap around you can have it all in one element. It should be passthrough and enforce dataflow, all of the use cases I have for this already have serialization. If I am not enforcing dataflow I am not likely to be writing left-to-right code but will fan out vertically and branching works just fine. These nodes take up enough room already let's use the real estate as efficiently as possible.

[AristosQueue (NI)]

The node as depicted has a pass through terminal for the cluster. If the node only unbundles and does not bundle, how comfortable would people be if the output terminal disappeared? In other words, that output terminal would only be present after you had set one or more elements to be Bundle and would disappear if all of them were changed back to Unbundle. Thoughts?

[tst]

If this was implemented, I would say that the pass-through should be there all the time, as the whole point of the request is to eliminate wire bends. I know it will be somewhat more difficult for NI, but NI already has the ability to detect that an output is unwired and react approriately, so I assume that "no output terminal" and "terminal not wired" should be the same for NI.

[Darin.K]

In other words, that output terminal would only be present after you had set one or more elements to be Bundle and would disappear if all of them were changed back to Unbundle. Thoughts?

Three words come to mind, no, no and no.

I can only speak to what I have personally done with a roll-my-own XNode, but in my version ALL terminals are available (input and output).  I can wire them up or not, and the final code is based on how the Node is wired, not how it is configured.  Very nice and very intuitive.  If you want passthrough for the cluster, just wire to the output.  Otherwise, don't.  Same for all of the elements.

Same here, that terminal should always be available, let the wiring decide.  I will just say that when I use my own version the number of wire bends and branches (at least visible ones) is greatly reduced.

[AristosQueue (NI)]

Replying to tst and Darin.K...

tst wrote:

> so I assume that "no output terminal" and "terminal not wired" should be the same for NI.

That's not the problem. It's a more fundamental problem. And maybe it isn't a problem, but it bugs me. A bit. See, you've got an output that is a value output that isn't ever modified by the node. So a user wiring it downstream has created artificial serialization of the nodes where none should exist. It's bugged me a lot when I watch people wiring LV classes... we made the default template for data accessor VIs have an object in and an object out by default, and at the time, I thought that was good, but I've been having second thoughts. Since this idea provokes the same question, it seemed relevant to raise it here.

This idea is about unifying the ideology of property nodes and (un)bundle nodes. We've often talked about the Timestamp as an example of a type that would have been done as a LabVIEW class had those been available at the time the Timestamp was created. There's a built-in node for "Get Date/Time String". That node takes a Timestamp in and outputs a pair of strings. I could easily imagine those being two properties of a Timestamp class -- Date String and Time String. The built-in node today does not have a Timestamp output. I think it would be weird if it did have a Timestamp output. And yet that's precisely what it would have if this were implemented as a property or invoke node.

I don't know where the line lies. Should "Flatten To String" have an output that is the original data? Why not? If we look to other languages, "To String" is a method on the data.

I'm hemming and hawing about this topic today because I'm looking at another proposed API, and something about it bothers me, but I can't figure out what exactly I don't like about it, but it has something to do with pass through terminals, and that dredged up the doubts I've had the last couple years about pass through terminals in general.

I'll probably let it go. But something still feels wrong. I just can't figure out what would make it right. Clearly therre are times when pass through terminals are desirable, and clearly there are times when they aren't, but where the line is remains something to think about.

[tst]

I see what you're saying and you're probably right that in some cases there's no need for a pass-through of the object, but in many cases (most?) there is and in any case, leaving it there means that people can use it, as opposed to not having it there, which means that people can't use it.

It's also correct that having the object out terminal encourages using the VIs in sequence, although I can say that personally I do split the class wire if I don't have room in my diagram. I assume that using the property node also helps (and that does require the object out terminal), but I can't say since I don't use 2010.