LiveCode Forums.

Posted: **Sun Mar 21, 2021 8:37 pm**

Hi @Craig, now after rereading this whole thread I understand what you mean. Or so i think

jjj
From what I can understand is that if you have 3 cases and none have a break. The LiveCode Script evaluates the first one that is true and will continue until it finds a break or the end of the switch statements, ignoring the other conditions that are in the other cases. But if doing what they are within these cases.
I think it's called a lazy algorithm or something like that that some guru can explain better.
It is also used in if statements
If Condition 1 And Condition 2 then
If condition 1 is not met, it will not evaluate condition 2, this is an advantage when coding and also makes our programs run faster.
I think that is the reason why it does not continue to evaluate the other conditions.

Posted: **Sun Mar 21, 2021 10:58 pm**

bogs wrote: Sun Mar 21, 2021 2:11 pm ...but doesn't allow you to forget to add the 'break' (as your case example is missing) hee hee

Yes it does.

I left it out deliberately, saving typing, because it is superfluous at that point, there being no further conditions, nor a Default. I tested my code for each of the conditions (and neither).

I'm sorry, I still fail to see any great reason to prefer one to the other based on some perceived 'block reading' ability

For me, I still find the Switch block more readable, so I think that part is a, er, case, of de gustibus no est disputandum.

cheers
David

Posted: **Mon Mar 22, 2021 12:12 am**

I am shocked to find it is hard to communicate precisely and coherently

. Some here, all rather expert in LC, only recently understood exactly what I proposed, and only then thought there was some merit in the, er, case. This is not unusual, and I know where most people's hearts are.

@Bogs You assert that if/then can be substituted for switch in *any* instance. I don't understand that at all, since switch obviates entirely the need for nesting. Nesting can get rather unwieldy in complex constructions, so all this talk about one-line statements seems unfair to the discussion; it is complex constructs that benefit from using "switch" instead of "if/then", not simple ones.

At heart, they do indeed perform the same task, but I would retain "switch" if I had to lose one or the other. Oh, in a heartbeat; a no-brainer.

This is the heart of the matter. "If/then" retains direct control over program flow from start to end. That is a powerful plus for it. "Switch" currenly contains within it an inherent limitation, in that it does not examine the totality of the (get ready for this) caseLoad. That is a debilitating minus for it, and is that "functionality left on the table" I am so fond of repeating.

I want to fix that. I think it would be a powerful new tool.

Craig

Posted: **Mon Mar 22, 2021 5:08 am**

Interesting thread.

I recently come across this method of using Switch and was a bit puzzled at first, but now I think I understand what's going on.

I've used the following function in an app that I'm currently developing, it's not my code, I'm sure it came from one of the LC tutorials, but unfortunately I can't find which one it was, if I could I would credit the author. I suspect it was something to do with data entry for a Data Grid, so maybe Trevor, but now I'm using it to filter the input for a pseudo table made up of 192 fields and it works well.

Code: Select all

private function _checkForInput pContent, pType, pMaxLength, pID
   local tResult
   put true into tResult
   
   switch
      case the length of field id pID >= pMaxLength and pMaxLength is not empty
      case pType is "number" and pContent is not a number
      case pType is "text" and pContent is a number
         put false into tResult
   end switch
   
   return tResult
end _checkForInput

This function returns "false" if any of the switch cases are met. To me it does look cleaner than a bunch of "if/then" statements and it uses a few less characters, probably computes a nanosecond faster too. The benefits here really are minimal, however, I felt the Switch without breaks was preferable to three separate if/then statements, so that's how I'm using it.

Alternative:

Code: Select all

private function _checkForInput pContent, pType, pMaxLength, pID
   local tResult
   put true into tResult
   
   if the length of field id pID >= pMaxLength and pMaxLength is not empty then put false into tResult
   if pType is "number" and pContent is not a number then put false into tResult
   if pType is "text" and pContent is a number then put false into tResult
   
   return tResult
end _checkForInput

Paul

Posted: **Mon Mar 22, 2021 8:01 am**

I am shocked to find it is hard to communicate precisely and coherently

Well: there are several things you have to think about there:

1. Whether you are being precise and coherent.

2. How other people interpret what you write.

3. Whether everyone else conceptualises about computer programming in the same way you do.

The answer to your 'problem' (and everyone else's) is probably a mixture of all 3 of the above.

Posted: **Mon Mar 22, 2021 9:09 am**

PBH wrote: Mon Mar 22, 2021 5:08 am Interesting thread.

+1

Hi all,

@Craig:
- do you know that
swift (Apple) promote the switch/case the way you want.

- do you know that
until recently, python had no switch/case statement
and when someone asked for an alternative,
the answer was the map() function, but not the if-then-else !

PBH wrote: Mon Mar 22, 2021 5:08 am This function returns "false" if any of the switch cases are met. To me it does look cleaner than a bunch of "if/then" statements and it uses a few less characters, probably computes a nanosecond faster too. The benefits here really are minimal, .....

Following your thinking and demonstration,
here is some variations of the 2 handlers you did show,
plus a last one being the logical root of all the previous one,
as I like concise and short coding style too.

Otherwise, I don't think any will be significantly faster.

Ok, we can compare these 2 coding style.
They are the same handlers as yours,
just did replace expressions with testA, testB, testC to focus on Switch vs IF:

Code: Select all

function checkWithSwitch1
   local tResult
   put true into tResult
   
   switch
      case testA
      case testB
      case testC
         put false into tResult
   end switch
   
   return tResult
end checkWithSwitch1

Code: Select all

function checkWithIfThen1
   local tResult
   put true into tResult
   
   if testA then put false into tResult
   if testB then put false into tResult
   if testC then put false into tResult
   
   return tResult
end checkWithIfThen1

Or we can compare these 2 more concise coding style:

Code: Select all

function checkWithSwitch2
   switch
      case testA
      case testB
      case testC
         return false
      default
         return true
   end switch
end checkWithSwitch2

Code: Select all

function checkWithIfThen2
   if testA then return false
   if testB then return false
   if testC then return false
   return true
end checkWithIfThen2

and finally this one:

Code: Select all

function checkWithBooleans
   return not (testA or testB or testC)
end checkWithBooleans

Have fun and enjoy this new day

Posted: **Mon Mar 22, 2021 12:55 pm**

dunbarx wrote: Mon Mar 22, 2021 12:12 am Some here, all rather expert in LC,

That certainly lets me out haha.

@Bogs You assert that if/then can be substituted for switch in *any* instance. I don't understand that at all,(1.) since switch obviates entirely the need for nesting. Nesting can get rather unwieldy in complex constructions, so (2.) all this talk about one-line statements seems unfair to the discussion; (3.) it is complex constructs that benefit from using "switch" instead of "if/then", not simple ones.

1.) it is my opinion (and practice) that nesting in an if / then statement means you haven't thought out the goal completely, but nesting does serve a purpose in very quickly setting up a test while thinking the end result out.

1a.) if you think there are not examples of badly nested switch statements, I don't know what to tell you.

2..) The talk about 1 line if then statements came about based on the examples you yourself gave, so I'd say they are fair, however, even written out fully, taking 2 statements and applying them in <switch case> or <if then> will always come out shorter and certainly more english like in an <if then> construct.

In my entire life, I've never heard even once anyone come up to me and say "switch the apple, case the pear" outside of a room of people coding. On the other hand, I can't imagine anyone never having heard "If the door is open, then close it".

3.) All of the examples given here are simple, but, regardless I think you have that wrong. The main advantage to <switch case> over <if / then> isn't code blocking, realistically speaking, the main advantage is <switch case> doesn't evaluate every single permutation.
It goes to the one case that matches and then bails <at break>, where as <if then> continues until you are done testing conditions.

So if you want <if then> comparisons to <switch case> that are neatly segmented or, alternatively, you think it is somehow impossible to craft an <if then> as neatly as a <switch case> substitute one for the other after you have written it out. You will I think find that except for the words "switch, case, break, end switch" there really is no difference using "if, then, end if" other than break is missing.

<pssssssstttttttt> you can add a break statement to an <if then> construct if you *really* want to, I'm pretty sure the galaxy will survive {but I have not tested this hee hee}.

**Disclaimer - I have in the early stages of my life written entire programs that were nothing but if / then statements just for fun. No animals were gassed out to extinction in the creating of this post. If water is entering your home, you might want to either make use of it, or stop it from being problematic.

Posted: **Mon Mar 22, 2021 10:31 pm**

I'm still not sure I understand the problem. I find the biggest advantage to switch is when I need to do something like Thierry wrote, though I do it this way:

Code: Select all

function checkWithSwitch
   switch
      case testA
      case testB
      case testC
         return false
   end switch
   return true
end checkWithSwitch

or

Code: Select all

function checkWithSwitch
  switch
    case testA
    case testB
    case testC
      return false
    default
      return true
  end switch
end checkWithSwitch

Maybe I need to see an example of a more deeply nested if/then.

Posted: **Tue Mar 23, 2021 6:45 am**

jacque wrote: Mon Mar 22, 2021 10:31 pm I find the biggest advantage to switch is when I need to do something like Thierry wrote,
though I do it this way:
Code: Select all
function checkWithSwitch
  switch
    case testA
    case testB
    case testC
      return false
    default
      return true
  end switch
end checkWithSwitch

much better; thanks Jacque.
I'm editing my previous post for that...

Regards,

Thierry

Posted: **Tue Mar 23, 2021 12:18 pm**

Hi,
may it be that you'd like to have a "continue" control structure analog to "break"?

What we have now, to end a statementList (commands to execute if the case statement is true):
"Break" - Skips the rest of the current switch structure and goes to the statement following the end switch.
[Empty] - Ignore all following case statements, but execute all following statementLists.

This could be added:
"Continue" - Continues the switch structure, beginning with evaluating the next case statement.

So this would work:

Code: Select all

   put 3 into myVar
   put empty into myRes
   switch
      case (myVar is a number)
         put " is a number and" after myRes        --  true!
         continue
      case (myVar mod 2 = 0)
         put " is even and" after myRes            --  nope.
         continue
      case (myVar = 3)
         put " = 3 and" after myRes                --  true!
      default
         delete char -4 to -1 of myRes
         put "." after myRes
   end switch
   put myVar & myRes
   --> 3 is a number and = 3.

Or have I mixed this up? ;-) Have fun!

Posted: **Tue Mar 23, 2021 12:28 pm**

We need to stop and think about the following situation:

Granny sends me out to pick up potatoes left after the harvest . . .

Last time I looked black, red, pink and yellow potatoes were fine, but green ones were not.

We can run a routine JUST checking for green-ness if that is all that interests us.

BUT Granny gave me a basket with 4 compartments for black, red, pink and yellow potatoes.

She has threatened to skelp me if I bring back any green potatoes.

Well, we could have an IF . . . THEN to exclude green potatoes, followed by a SWITCH to sort
the remaining potatoes by colour.

And, as far as that example goes that's all possible.

BUT, life gets a lot more awkward when it turns out the slightly bonkers farmer planted mixed potatoes and sweet potatoes.

So . . . 3 types of sweet potatoes; pink, yellow and brown have to be differentiated from 'spuds' that are pink, red, yellow and black.

: Sweet Potatoes; potatoes_sweet.jpeg (7.4 KiB) Viewed 15328 times

-

: Potatoes; potatoes.jpeg (6.43 KiB) Viewed 15328 times

-
Thinking about a potentially real-life situation can prove useful.

Posted: **Tue Mar 23, 2021 2:31 pm**

Axwald.

Vegetables, aside, yes, a new keyWord would do it all. Your "continue" is much better than my "busted". I was stuck on something similar to "break", or at least starting with the same letter, and now regret it terribly.

Simple to implement? Not sure. Will change the world? Not sure, considering that several here think "if/then" is all we need.

Craig

Posted: **Tue Mar 23, 2021 2:47 pm**

@andrest

I think it's called a lazy algorithm or something like that that some guru can explain better.
It is also used in if statements
If Condition 1 And Condition 2 then
If condition 1 is not met, it will not evaluate condition 2, this is an advantage when coding and also makes our programs run faster.
I think that is the reason why it does not continue to evaluate the other conditions.

Yes, laziness increases execution speed, at least on my Mac, if not in my life.

But sometimes I want to evaluate a suite of conditions, some true, some not, so that I can collect all the true ones and ignore the false ones. That is why I think enhancing "Switch" would be so useful.

Craig

Posted: **Tue Mar 23, 2021 2:59 pm**

dunbarx wrote: Tue Mar 23, 2021 2:31 pm Not sure, considering that several here think "if/then" is all we need.

I'm not entirely sure anyone, including myself, thinks <if then> is the end all be all. Certainly if your looking for test / rejection, <switch case> is the tool for that. My only real suggestion is using the proper tool for the task, and that <if then> vs. <switch case> is {or can be} a wash as far as code block cleanliness goes.

I just happen to think <if then> is also a more natural language construct.

Posted: **Tue Mar 23, 2021 3:48 pm**

a more natural language construct

When I go shopping, when I don't find the first thing on the shopping list I don't pack up
and go home, I see if the next thing on the list is there . . .

So, a modified SWITCH should NOT be ONE condition or Reject: it
should allow for multiple conditions . . .

Why does this make me think about that discussion about drop-down menu buttons with multiple selectable
items?
-

LiveCode Forums.

Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch

Re: Rehashing Switch