Allow Multiple Case Selectors

[Darin.K]

First of all, this is not a duplicate of this, by Case Selector I mean Case Selector and not the label.  It may well be a duplicate of something else...

I doubt that I am the only one who uses multiple conditions.  This usually leads to nested Case structures, building boolean arrays, or obfuscated mapping functions between the conditions and some enum.  Other times, the case structure is half-of-a-screen wide just to accommodate the values associated with the different cases.  I would suggest that NI add multiple Case Selectors to the Case structure.  Additional selectors could be pulled down like a shift register, or added via a right-click menu.  Either way, I don't think they should be allowed to cross, so the top-down selectors map to left-right selector labels.  There could be a reasonable limit to the number.

[JackDunaway]

This may be essentially a duplicate of Cluster to Case Selection. My second comment on that thread, albeit dramatic, is applicable here as well. The only difference is the original Idea wires a cluster directly into one case selector, while this Idea fans out data elements onto the Case Selector interface (which fixes some other problems the original Idea might run into... I don't know, perhaps a structure like this would be feasible).

[Darin.K]

That was close, but I am not looking for the selectors to be any different than they are now, just to allow multiple ones with the implied AND between them.  You'll have to explain the slippery slope you see here, this idea simply allows a restructuring which can remove nesting these structures and label obfuscation for multiple comparison types.  It is fully determinable at compile time that all cases are covered just like the current case structure. 

What did happen, however is that I posted my image without saving all of my butchering, I meant for the selector to look like this.

[PJM_Labview]

So, you imply an AND operation. What if the user want to do something else? Maybe you should also have an operation selector of some sort (between the other selector) to specify the nature of the operation.

Note: Of course there should be more than just AND, OR in the list (when appropriate)

[JackDunaway]

OK, after some thought, I want to repeal the comparison to the Cluster to Case Selection Idea. While the other Idea could not guarantee the combination of inputs would map to one case exclusively, implying AND between case selectors can allow the compiler to guarantee mutual exclusion of cases. Plus, this Idea does not modify the behavior of the Case Selector Terminal or the Case Selector Label.

If cases are not mutally exclusive (which is easy if the OR operator is introduced), a priority would need to be assigned to cases, where only the highest priority case would execute (e.g., case closest to the top of the list). Otherwise, shift registers and a "break;" equivalent would need to be added to the case structure (to simulate the "switch" statement in C).

Issues:

1. Is there a "Don't Care" designation for inputs? How does that relate to the current "Default" case?

2. How does top to bottom order of Case Selector Terminals affect left to right order of Case Selector Labels? Are Terminals/Labels assigned a Label or Index as an identifier?

I'm really wanting the usability and logic of this Idea to pan out, because it could appreciably simplify syntax.

[Darin.K]

@PJM_Labview:  Sticking with just AND allows this to be a refactoring of nested Case structures.  There are certainly pitfalls to the other operations, such as multiple cases being true.  I have to think about this a bit more, but it is certainly beyond what I am ready to advocate for right now.  I am trying to crack open the lid to Pandora's box, you are suggesting to use Nitro to get it open.  I forget AQ's stats, but this guy ranks right up at the top of most used objects, so big changes lead to big scrutiny which leads to exponential decrease in the odds of getting anything done.  Perhaps a new Switch-like structure would be in order.

@Jack:

1. I believe that Default should cover the 'Don't Care' designation.  I like the idea of having a None of the Above case which would be all inputs set to Default.

2.I thought of the shift register analogy specifically because I do not think that selectors should be allowed to cross.  I like the idea of pulling down two or three selectors.  At any rate there must be a strict mapping, the natural choice seems to be top-down for selectors, left-right for labels.  (We should be able to add Labels to the Selector labels IMO).

My other thought is that it would be great to be able to "link" cases.  Right now, you have to have a comma delimited list to have multiple selections linked to a case.  I would like to have two or more separate Selector labels bring me to the same case.  We would need a glyph (think chain) to show that a certain case is linked to others.  (Still an IIP- Idea in Progress).

[Manzolli]

I would like, for a little start, only the implementation of the "or" option. This looks very intuitive and useful, since avoids making copies of the cases that have same (or almost) code.

[AristosQueue (NI)]

I'm not sure how I feel about this feature, but I'd like to share something from a professor I once knew. He would oppose this feature because, he would argue, it promotes bad code. I'm curious how the community reacts to his reasoning...

Currently LV has a case structure that can make decisions on a single variable. It is easy for a programmer to guarantee that all possible values of that variable are routed to some particular case and to note exactly which case it is. Yes, we have a "Default" keyword, but you can clearly see the cases that are broken out.

Now, the professor was talking about if statements in C++ and JAVA code. He noted that a significant source of bugs is if statements that are not fully tested. When an if statement evaluates a simple true or false condition and chooses a path, it is easy to write tests that pick between them. When a switch statement (the equivalent of a LV Case Structure for non-boolean values) fans out to several cases, it is easy to write tests that fan out to each possible case. But if I have a single if statement that is evaluating lots of values from lots of sources, it is very hard to identify all the ways that the statement might be false. He argued that something like LV's existing Case Structure should be applied to those other languages in order to lower the complexity of the code, even though more code was actually necessary.

Suppose someone writes this code:

.  if (((string == "MyString") and (number == 9))  or ((string == "OtherString") and (number == 8))) then

.      DoX

.  else 

.      DoY

The programmer now needs to write test cases for the code. According to the professor, the tendency among most programmers would be to write two test cases: one that executes the true case and one that executes the false case. The problem is that there are many ways that the if statement can be false, and all of those need to be tested.

But what if we restrict the if statement to only test one variable and make only one evaluation against it? Here is the same code written with that restriction:

. if (string == "My String") then

.       if (number == 9) then

.            action = "DoX"

.       else

.            action = "DoY";

. else if (string == "OtherString") then

.       if (number == 😎 then

.            action = "DoX"

.       else

.            action = "DoY";

. else

.       action = "DoY";

.

. if (action == "DoY") then

.     DoY

. else

.     DoX;

In this form, the professor argued, more programmers are going to recognize that there are five code paths that need testing. In LabVIEW, every single one of those assignments to the "action" variable would be an assignment to a case structure tunnel. This form of the code requires more typing (or, in LV's case, wiring), but the ability of most people to read the code and figure out whether all the code paths are the correct code paths appears to increase.

I'm not sure if I buy the argument or not, but it seems plausible. It would require significant usability studies to determine whether this is true or not (and I've long ago lost track of that professor). But if it is true, then LV's Case Structure as it stands today is arguablly preferable, particularly for use in test and measurement environments, if only because it forces developers into a particular style of development for which tests may be more readily written. Of course, if the argument is false, then today's case structure is forcing a huge amount of clicking that could be eliminated by augmenting its selection capacities.

I've certainly written LV code like the second form, but I don't have any personal data to back this argument one way or another because I don't really know if I would have botched my testing if I had written the code differently, seeing as how LV doesn't have the first form, and I pretty much don't do this in other languages because they do have the first form. What does everyone else think of this argument?

[tst]

I would argue that most users don't write automated tests for their code anyway, so the apparent improvement in readability would outweigh that consideration (I say apparent because I would need some proper examples to determine whether or not this actually helps. I can certainly see a situation in which nesting is actually more readable). I voted for the idea because I think it's something that's worth looking at.

[Darin.K]

My initial thinking is that applying the Professors logic to LV would actually favor this construct over the nested cases (although I rarely put much stock in C vs. LV analogies).  My reasoning is that with this construct, all possible cases are visible from the outermost Case structure, so readability is improved (IMO).  Sometimes more code would be necessary since some nested cases share code from the parent case.  Like C, you could still choose the old-fashioned way if you enjoy all of the extra clicking,

Let me again stress that allowing OR like the C analogy may make things hairy.

[Vaibhav]

My reasoning is that with this construct, all possible cases are visible from the outermost Case structure, so readability is improved (IMO).

I would say, with this new construct, the readability will NOT necessarily be improved in all the situations. What you might be trying to say is, perhaps, "visibility" will be improved (given all code is in one box and no more sub-boxes). But for the readability concern, I would prefer the current system. Speaking philosophically, the Professor is right about programmers often failing to "understand" the logic in simple terms and try to implement cases without proper testing. And this mainly happens when the programmer is not "clear" about his logical conditions. And that's what might kill the application given such a "dangerous tool" in the programmer's hands.

However, I also liked this idea, because this would make my code much simpler, and readable also, in my case. 

I would say, multiple selectors will be great, and those who are sure about implementing their code without bugs should be able to use this tool. In those "doubtful" or "uncertain" cases, the programmer may still use the current case structure (by not adding any extra selectors). 

I am in favor of the new idea.