If Case Statements

I thought I’ve seen some examples in here before, but now I can’t find any, and I can’t seem to figure it out on my own.

I’m looking to to use a conditional statement in RM 4.1, where the IF statement uses the value of single variable to set the value of another variable. I would normally know this as an IF/CASE/END IF condition, for example:

If %VarA% =
CASE “1”: do this thing
CASE “2”: do another thing
CASE “3”: do this 3rd option instead
CASE “4”: just do this 4th option
END IF

Of course, I can do this with a group of IF statements, but I really like the cleanliness of using an IF/CASE/END IF statement.

Is this something that is possible with RM 4? Is so, how do I do it?

Nope. You are going to have to use IF/ElseIF/Else

3 Likes

I'm not sure what examples you've seen, but Rule Machine does not have a way to do something like switch ... case (as in C-style languages, including Java/Groovy) or if case ... (guessing you're getting that from Swift?). You will have to use an IF THEN ... ELSE-IF THEN ... END-IF. The only notable difference is that you'll have to provide the variable name in each condition. I don't see any way this would provide a difference in functinoality, so I'm assuming it should work for you.

If you're writing a custom Groovy app, however, then you can certainly use switch in your code as you se fit. :slight_smile:

5 Likes

I do too. But since it doesn't exist, I have been known to use simple IF/THEN conditionals if the "cases" are mutually exclusive. This makes the rule easier to read and maintain, and the inefficiency is negligible in most instances. For example, I would write

IF Sunday THEN Sunday Action
IF Monday THEN Monday Action
...
IF Saturday THEN Saturday Action

Of course, this won't work if the cases are not mutually exclusive such as

IF Temp < 30 xxx
IF Temp < 20 xxx

I run hot and cold on that :-). In programming generally (usually Perl, that's where I'm most likely not to have a real 'case' statement). It's kind of elegant, but if the conditions change then the interaction of the statements may change in the future, and future me might then be cursing past-me's name. I mostly stick with the if-then-elsif-...-else.

2 Likes

I'm absolutely with you on that. I cannot defend it as a good way of programming; I can only say that in the absence of CASE and in the RM UI, I can do it and still think well of myself.

I wish that the RM dropdown for conditional actions would allow you to select IF/THEN or IF/THEN/ELSE and then it would proceed to put the entire structure including ENDIF in, properly indented so the blocks would be clear.

1 Like

The problem with this is what becomes of the locus of insertion of new actions? Ordinarily that locus is the bottom of the list of all actions. If it just drops these in as you suggest, then you would have to use Insert Action to put what goes after IF-THEN or after ELSE in the right place. This would become its own set of confusions and errors, wouldn't it?

1 Like

Absolutely agree. Especially with nested if’s.

1 Like

Point taken, but I wouldn't mind at all specifying Insert instead of defaulting to the end of the list. It would be interesting to count the number of mouse clicks required with each approach. The ability to see the proper indentation as you enter actions would be very helpful in reducing visual complexity.

I get this, but it does it already. That is, after you put in IF-THEN it automatically starts indenting.

There is perhaps another way to make these easier. I have to play with the UI a bit to check it out.

2 Likes

In theory, there could be many ways to design an interface to create rules. From the many times that you've responded to suggestions (complaints?) about the RM4 interface, I've gathered that the interface is so tightly tied to the underlying logic that you don't see an easy way to separate them.

If you're seriously asking for feedback on the UI, I think there are plenty of ways to design the interface so that a "dropdown for conditional actions would allow you to select IF/THEN or IF/THEN/ELSE and then it would proceed to put the entire structure including ENDIF in, properly indented" in a way that would also guide the user to the correct place to proceed for inserting the new action.

The interface could use fonts, colors, cursor placement, line numbering, etc. to guide the user to fill in the actions within the skeleton of an empty IF/ELSE/END-IF block, rather than always defaulting to appending at the end of the rule being edited.

The UI isn't as flexible as you make it out to be. It isn't really interactive, with a cursor or something to guide you. What the "correct" place might be is totally subjective. Suppose it pre-filled IF-THEN, ELSE, and END-IF. You've got three places (before ELSE, before END-IF, after END-IF) where actions might want to go after that, not counting inserting an action somewhere else in the list next. How to cause actions to go into which one of those becomes the problem.

I'm responding to ideas that people have, that I've actually thought about. I'm not in a position to chuck the RM UI and make a new one from scratch, or drastically redo what's there -- at least not this week. This is a topic discussed quite a bit.

PLUS: I'd bet dollars that adding pre-fill of ELSE and END-IF as more options would increase confusion well above where it is now.

6 Likes

Yeah, I certainly would not want that. I will decide whether it’s ELSE, ELSE-IF, or END-IF I want and need.

3 Likes

Here is the sort of thing I'm thinking about:

Having just created an IF-THEN, lo and behold two buttons appear labeled ELSE and END-IF. Clicking one of those would add those onto the list of actions without all of the other clicking about.

This would be context sensitive -- these buttons would only appear when adding one of those makes sense -- and it would keep track of the nesting of conditional actions as needed. The indentation would just follow suit. There could also be a button for END-REP, same concept.

What I just showed was the easy part, making the UI display those buttons. To make them actually do what I said is a bit more effort... This will have to wait for a bit.

Question is: would this help?

14 Likes

It would reduce clicking for those that know and for those that don't it may have an additional benefit or pointing them in the correct location. That can only be a good thing?

3 Likes

Oh, I was under no illusion that the UI is flexible, based on what you've written before. I was merely pointing out that -- in theory -- a UI could be designed with many possible ways to guide users.

I'm really not a developer (my serious software writing stopped shortly before C++ became widespread), but I create way too many scripts and do stuff with a significant HPC facility. I often hear software developers -- and myself -- saying why something can't be done, or why the technology debt (legacy code, etc) is too difficult to overcome, because they have a deep understanding of how the current situation came to be, but less of an awareness of alternatives.

Perhaps HE (and your customers) would benefit if someone who's less familiar with the history of the product worked with you on the UI design.

Yep, pretty much any number of things could be done in theory. The discussion above was about a specific problem set with the current app. Sometimes when people have good ideas about RM they get implemented. Other times I encourage people to create a new and better rules engine with a different/better ui. Two very different topics, don't you think?

3 Likes

Hi all! Thank you so much for your input! I love to see all of these discussions. The particular situation I’m looking at would have been nice using a case switch type of thing, but like I said - I can totally do it with IF/END IF statements and it will work fine. I’m probably remembering some groovy code stuff I had seen and getting it mixed up.

Chances are, I may end up writing a small groovy app eventually - but I’m not ready for that yet. Gonna try it with RM and build my skill set as I go. Thank you!

1 Like

I think this would be very helpful and reduce keystrokes. If you add too many else statements its simple to delete some later.

Well, you wouldn't be able to add "too many", because there is only one ELSE per IF-THEN. The code is able to know this and only allow one. Another one that pops out is that you can't have an END-REP for a Repeat if you are inside an IF-THEN inside the repeat loop. And, of course, there is only one END-IF that matches up to each IF-THEN. etc.

2 Likes