Show/Hide reference terminals directly on controls

[SeanDonner]

One of the fundamental idioms in LabVIEW is "never use a local variable when wiring directly from/to the control will suffice."  As many of us know, local variables break the dataflow paradigm and should only be used in cases that necessitates them.

No doubt there is much value to using references to front panel controls in architectures such as a QSM, however, I felt like I was commiting sacrilege every time I was forced to wire these references from local variable-like reference nodes while leave dangling controls hanging about. 

Every control has a reference to it under the hood, so why not have the ability to show a reference terminal on the control itself; this way we can start our reference wiring straight from the control itself. 

 Control Values

                   

---

Control References

              

---

I suggest we show/hide the reference terminal using the same method Shared Variables show/hide the timestamp terminal

[SeanDonner]

I should have read the post you linked to first but...

"Somehow we have this G-world where values flow through wires (unless you are one of those people...), and references just float through the ether."

^^^^^This!  Exactly this!  

[Intaris]

---

Your statement is factually correct but you would not do as you said even if we were talking about control values.  If you wanted to use a control value in more than one place, you wouldn't duplicate the control nor should you create a new local variable from the control, you would branch off the value wire which leads back to the control.  Similarly, if you needed to use the reference in more than one place, you branch off the reference wire rather than create a new local variable-like reference node; again this is all under the assumption that you can branch off the wire.

---

I'm really not sure which problem you're trying to solve with this idea.  It sure creates new problems, that's for sure, so the benefits would have to be great to make the idea worthwhile.  Regarding Altenbach's comment earlier, how would you deal with processing of the reference if the terminal for a control is within an event structure but you want to do some UI operations ont he control outside of this loop (As per standard producer consumer architecture).

If your problem is with the graphical representation of references, then suggest a change to that instead of making suggestions which address a non-existant problem.

[SeanDonner]

Intaris, you have completely misinterpreted the intent of my idea.  The goal is not to replace the current method of using references, but rather to suppliment it by allowing control refences to flow out the terminal they refer to. 

Please read the post on the previous page to tst which I believe does a fair job of explaining the intent.  Here is a pertient quote from that post:

> Now let me be clear, just as there are completely legitimate uses for local variables, there are certainly legitimate uses for having reference

> nodes be local-variable like; altenbach came up with some very good examples of those.  It may even be that the cases for when my idea

> could be utilized would be a fraction of the cases for when you would use reference nodes as they currently exist; but I still believe that we

> should have the option to do it my way nonetheless.

For the record, I consider the fact that "references just float through the ether" a very real problem when dealing with a dataflow language.

[tst]

OK, so now at least I see that you don't have a misconception (I thought you didn't really understand the distinction between the value and the reference), but rather just another way of looking at things. I still don't think I would want this because for the vast majority of the controls I use I don't need the reference and for the small number that do need it I think I would prefer a separate terminal for getting the reference, both for the reasons Altenbach mentioned and because I think it would be easier to read.

Maybe it just comes down to personal preference of whether having the refererences separate is something you "get" or not. Apparently you, your students and Darin think it would make more sense if it was together and we don't.

That said, if you can demonstrate a reasonable complex diagram where something like this could help make the code more readable, it might get people to vote for this. I personally don't think I would, but others might.

[Intaris]

@SeanDonner

Nope, I don't think I HAVE misinterpreted the idea.  I understand fully what you want but it just doesn't make sense to me.

Allowing an extra "special" reference tied to the control terminal whilst other "ethereal" references being still allowed only serves to INCREASE the complexity of the code and the language as a whole because we now have ANOTHER terminal type to focus on.  Just adding ANOTHER way of representing references solves exactly ZERO problems because your nemesis ("ethereal" references) are still there and still look like local variables (in your opinion).  Therefore I would reiterate that perhaps refocussing on actually fixing the part of the "ethereal" references you don't like would be a better approach instead of weighing LV down with yet another terminal option.

You end your response with the text:

For the record, I consider the fact that "references just float through the ether" a very real problem when dealing with a dataflow language

but again: your proposed idea does NOT solve that problem.  It only solves maximum ONE instance of an "ethereal" reference.  Not to mention implicit references (Passing to sub-vis).

I also refuse to see how using references in the manner so abhorrent to yourself is a real problem.  I've been doing it for more than a decade (not wantonly, only where it is required).  Is it confusing to beginners?  Yeah maybe.  But if we start changing things based on that we'll have to remove User Events, Occurrences, DVRs, LVOOP and a whole host of other things.

[AristosQueue (NI)]

SeanDonner: I fully agree with Intaris. This idea would link together the control ref for one and only one way of obtaining that control ref to the FPTerminal. There are many other ways to get the ref -- get a VI ref and ask it for all of its controls, for example. Or have a control ref passed into the VI and then obtain its value in a local variable. This is at best a minor confusion for new users and is at most a valuable feature. Once you're dealing with references, you have to design for disconnected usages anyway.

The real solution, obviously, is for a programmer to stop using references so much that he or she gets confused by the nest of them.

[Darin.K]

Let me suggest a probable motivation against this idea, since it is bascially what kept me from ever posting it here.  LVers love their wires and dataflow (Go with the flow, man!), until said wires start crissing and crossing on their BD.  The premise of this idea is absolutely correct, implicit references break dataflow, (other methods such as passing refs are following dataflow and are not implicit).  People see this and immediately see more wires on the BD.  Think it does not matter?  Check out the IE for entries that remove a 2px bend in a wire and see how many Kudos they have.  (Hint, look closer to the top than the bottom of the leaderboard).

LV loves to be by value, except when it isn't.  It loves to be dataflow, except when it isn't.  It can be maddening for CS types who like strict rules, but the engineers for whom it is primarily built get decent mileage out of it.  Adding wires for the sake of proper dataflow is just an uphill battle.

I am not afraid to advocate for what is proper (dataflow) over what is in my self interest (fewer wires and cleaner BD), but when there is not a real threat to my self-interest it is even easier...