>Im sorry but those coloured diagrams are terrible. I suddenly feel like I know what an LSD flashback must feel like...
Agreed. That's why I said: "please don't". And I deliberately used those colors to show how terrible this feature is . It's just as bad for other colors, at least for anyone but the offender.
Sorry for mentioning it, but it was called for (literally).
Speaking purely for myself -- I have not discussed this with the rest of LV R&D.
I dislike this idea a lot.
It causes needless serialization of by-value data. I might be ok if this was restricted to refnum types (those often need serialization), but your example is an integer, so all you're doing is slaving potentially-parallelizable code to run downstream of the loop for a bit of wire savings. To balance the cost of runtime downside, the edit time upside had better be major but...
... it is a fairly minor savings for wiring.
It hurts diagram readability. It is yet another unintuitive diagram marking with a magical meaning. That might be ameliorated with different glyph design. Intaris et. al. propose a universal "paired tunnel" concept. This does help with the readability a bit, but, again, it's being used for serialization of a by-value type -- see objection 1.
yup... it ultimately boiled down to a "paired tunnel", with a hint of shift register in it
serialization of data may not be as bad as you think, you can creatively use it to enforce sequence, rather than the conventional error wire or flat sequence method. if the processes necessitate parallelization, you can always branch the wire out, like the conventional approach. and if you want to strike a balance between them, can consider adding in an additional option "read only" to the paired tunnels, which retains the data without the option of overwriting it (a pure feed-through); hence allowing it to be passed to parallel processes from the point of entry.
a "feed-through option" as default also offers much convenience in wiring across case structures without having wire them individually, especially for complex structures.
the idea is originally proposed in hopes of reducing the wire clutter resulted from wires wrap-hugging structures, whether it is wired to the structure or just passing by. It is ironic that a clean-up often causes mess-up instead.
Jet there are no alternatives. The root of the problem to me is "how do we get unused wires to the other side of the structure that uses some other wires".
I've heard JeffK uses stacked sequence structures for this. Guess that works, but isn't great. It's hard work to add a SSS to every one of my cases in a event structure or state machine. That could easily add >50 SSSs just to get style guided code...
The "Default values case" solution would work, but it would be weird to have a case in loops... And it's just hypothetical for now...
It's one of the problems we all have to deal with in a lot of code, but I think we've all just excepted it as it is. I simply allow my wires to go behind structures, as all other alternatives are either way too much work, or just as kludged.
I'd like a permanent solution, but if it was easy we'd already have it.
Would a better idea be to improve the obviousness of wires behind structures? Something that makes them stand out visually along with an easy way to see which ingoing wire goes to each outgoing one.
A: By reducing it to a single wire and using something similar to unbundle and bundle?
What if structures could have input and output terminals like a formula node, but in pairs as inputs and outputs? Then internally access them from a wire similarly to a cluster? Almost like the reverse of an in-place element structure. The "cluster" would be a purely IDE construct (no contiguous memory).
