> What if structures could have input and output terminals like
> a formula node, but in pairs as inputs and outputs?
See my previous post on excessive serialization. In general, I'm going to oppose any output terminal whose value isn't potentially different from the inputs of the node (refnums are special in this regard). This applies to all nodes, including but not limited to subVIs, to built-in nodes, and to structures. Slight exemption for error clusters, but, honestly, I've been writing more and more VIs with an error in and no error out when the node itself cannot produce an error but I still want to skip its operation if there's an upstream error.
Bring the value around on a wire. Please stop trying to "solve" this problem. The code is more readable than any magic jump that we add to the language, and the performance is better if you allow parallelism to happen.
If you want to propose editor tweaks that make it easier to draw that wire around or that encourage the wire to stay out from under the structure when the structure resizes, I'm fully on board with those.
OK, it's clear what I had in mind didn't communicate well (again). The whole idea of my last suggestion was to put everything on a wire, but without overhead of building an actual cluster (because I can already hear the pushback based on that just by thinking about it). Not terribly important.
IMHO the wire clutter itself (ironically looked like spaghetti) is already a problem that is shying people off, it needs to be recognized and solved.
back to discussion, a look at the conventional flow chart may have something that can work. an on-page/off-page connector, which allow wires to jump across sections/pages of codes. a set of (single writer, multi reader) polymorphic connector nodes could be a good in making things clean and readable.
acts like a local variable, but have no FP objects.
acts like a global variable, but automatic creation and naming.
nodes can expand to include more terminals, but if passing bundles no difference
As of the original "retain value if unwired", suggest to be reserved for case type structures only.
AQ Wrote> Bring the value around on a wire. Please stop trying to "solve" this problem. The code is more readable than any magic jump that we add to the language, and the performance is better if you allow parallelism to happen.
It's not about "the value". In a decent event handler, there could be 1-20 wires. Routing all those wires around is a mess waiting to happen. Putting them on top, and have them jumping up and down when needed is a pain as well.
I think it would be more readable if there was a special structure (or the In Place Element Structure) that allowed an in and out without a wire in it's diagram.
> In a decent event handler, there could be 1-20 wires.
*grin* I think in a decent event handler, either those 1 to 20 wires are a single array or cluster or class that is carrying the coherent state data OR those 1 to 20 wires are not all going to the same place.
But let's talk about your indecent event handler.* 😉 I'd rather not discuss hypotheticals. Do you have any diagrams with more than 3 wires routing around that you could share here? I don't have any like that that I can recall ever writing. If you can post the full diagram, there may be something deeper worth looking at in the programming environment.
* Note to other readers: Wiebe and I know each other... I'm joking with him here, not trying to insult his code. He's a strong G programmer, and I'm genuinely curious to see one of these complex wiring scenarios since I've never encountered one in my own work, but my G tends to specialize in library writing, where as he is doing more full-scale applications.
>*grin* I think in a decent event handler, either those 1 to 20 wires are a single array or cluster or class that is carrying the coherent state data OR those 1 to 20 wires are not all going to the same place.
That was to be expected .
(Authentication failed, so this 2nd post is a bit more verbose then my 1st. sigh).
There is some coherency between some of those objects, but not enough to group them.
A cluster would work, there will be less wires, but at the cost of having to unbundle\bundle all the time, with a terrible wire mess as a result.
A container class would simply obfuscate a lot of code, and it's usually a pretty stupid experience having to wrap each function in class A in the container class. It just feels like a big waste of time for me. There are some container wires, but I've drawn a line where it became unpractical.
Note that all of those classes are used in other contexts as well.
Some will be refactored out, as they can (now, after the code evolved) be a child of an existing class.
Biggest issue is that some classes need to handle events. When they do, they need some of those other objects. So any kind of parallel even processing will fail, unless I switch to by reference. Everything is by wire now (as it should IMHO). Switching will just shift the problem from data access problem to synchronization problems.
This stops me from making completely stand alone modules out of some classes\objects.
All in all, besides some parts not being completely modular (and therefor needing wires in this event handler) and some wires going beneath structures, I'm OK with it.
What follows is somewhat stream-of-conscious as I muse about various things this diagram makes me think of. I did clean it up some after writing it, but it does jump around topics a bit.
The original request asked us to add a way for data to jump over loops. Even though the conversation has broadened to "jumping over all structures", I've been sort of still focused on the loops because that was a major sticking point for me to accept "all structures".
In this picture, the one wire that appears to argue for some sort of "jump the loop" -- the top-most wire for "handling dynamic panes and control scaling". It is read-only within the loop and output through a tunnel. Presumably, it is chock full of refnums, and, as I've said, I'm open for discussing this sort of jumping feature for refnums because they do have a dependency on the loop completion, unlike by-value data. The tricky bit that Wiebe shows is a class (itself a by-value type) that is behaving like a reference type (because its internal data is references). I admit that it is a good argument in favor of the jump-ability, but I'd probably only accept it for classes, clusters, and arrays that exclusively contain refnums. (It would be an awkward thing for classes because it would leak info about the private to the public API. On the other hand, a class that is exclusively refnums is "allowed" to do things that classes containing values do not, so maybe making a language feature dependent upon that condition is acceptable? Not sure... doesn't feel good to me, but I could be talked into it maybe.)
Still, for saving that one wire, just having it go around the case structure seems reasonable to me.
So let's look at the inside of the event structure where we have many wires that could want to jump around the case structure.
Let's start with the linked tunnels feature. Notice that Wiebe is already using the feature of LV that allows you to link an output tunnel to an input tunnel so it is autowired as you add new frames. When that feature was designed, R&D deeply explored the idea of not requiring the wire across. Spent rather a lot of time on that. Looking back at the spec, there was a lot of concern for code readability -- there's not a lot of room on a tunnel to provide different flavor indicators. This idea suggests that we should revisit the decision.
Yes, that "handling dynamic panes and control scaling" class is by reference. It's actually a daemon or actor, so a dynamic VI is started by the init. I can use by reference here, as I know I never going to debug the class when the main is not running. It handles creation and deletion of panes and splitters. I'll do a presentation on that at GDevCon '18.
Note that in that case there are 9 wires going through. Only 1 use used, 8 are not. The unused ones are simply stealing space from the diagram, preventing me from doing useful things. This diagram is simple (as it should be), but some are a bit more complex. I have to either code over wires or route those wires around the code. Both are not ideal.
Note that I already keep linked tunnels at the same height. It makes much more sense to me that way.
If those tunnels would not require wiring, I'd say the height should be automatically linked. Otherwise, A and B inputs could be linked to C and D, where A would be on top and D would be on top. That would cross the signals, and that would be terrible to read or debug.
>(It would be an awkward thing for classes because it would leak info about the private to the public API. On the other hand, a class that is exclusively refnums is "allowed" to do things that classes containing values do not, so maybe making a language feature dependent upon that condition is acceptable? Not sure... doesn't feel good to me, but I could be talked into it maybe.)
That would only make sense if LabVIEW had a feature to turn a by wire class (or object?) into by reference class (object). Or an option to manually mark it as by ref\wire. That way there would be a "formal" distinction between by ref\by wire, and that could be indicated visually.
I think it would be pretty tricky to let LabVIEW decide what is by ref or by wire. For instance an private data integer ID to a global buffer would conceptually make the class by reference, but technically it's by wire.
