Rehashing Switch
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Re: Rehashing Switch
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.
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.
Re: Rehashing Switch
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).
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.I'm sorry, I still fail to see any great reason to prefer one to the other based on some perceived 'block reading' ability
cheers
David
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Rehashing Switch
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
@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
-
- VIP Livecode Opensource Backer
- Posts: 129
- Joined: Sun Feb 20, 2011 4:26 pm
- Location: Vancouver Island, BC, Canada. ex.UK
- Contact:
Re: Rehashing Switch
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.
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:
Paul
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
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
-
- Livecode Opensource Backer
- Posts: 9388
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Rehashing Switch
Well: there are several things you have to think about there:I am shocked to find it is hard to communicate precisely and coherently
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.
Re: Rehashing Switch
+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 !
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
Last edited by Thierry on Tue Mar 23, 2021 6:46 am, edited 1 time in total.
!
SUNNY-TDZ.COM doesn't belong to me since 2021.
To contact me, use the Private messages. Merci.
!
SUNNY-TDZ.COM doesn't belong to me since 2021.
To contact me, use the Private messages. Merci.
!
Re: Rehashing Switch
That certainly lets me out haha.
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.@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.
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.
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Rehashing Switch
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:
or
Maybe I need to see an example of a more deeply nested if/then.
Code: Select all
function checkWithSwitch
switch
case testA
case testB
case testC
return false
end switch
return true
end checkWithSwitch
Code: Select all
function checkWithSwitch
switch
case testA
case testB
case testC
return false
default
return true
end switch
end checkWithSwitch
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
Re: Rehashing Switch
much better; thanks Jacque.jacque wrote: ↑Mon Mar 22, 2021 10:31 pmI 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
I'm editing my previous post for that...
Regards,
Thierry
!
SUNNY-TDZ.COM doesn't belong to me since 2021.
To contact me, use the Private messages. Merci.
!
SUNNY-TDZ.COM doesn't belong to me since 2021.
To contact me, use the Private messages. Merci.
!
Re: Rehashing Switch
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:
Or have I mixed this up? ;-) Have fun!
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.
All code published by me here was created with Community Editions of LC (thus is GPLv3).
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
-
- Livecode Opensource Backer
- Posts: 9388
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Rehashing Switch
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.
- -
Thinking about a potentially real-life situation can prove useful.
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.
- -
Thinking about a potentially real-life situation can prove useful.
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Rehashing Switch
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
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
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Rehashing Switch
@andrest
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
Yes, laziness increases execution speed, at least on my Mac, if not in my life.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.
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
Re: Rehashing Switch
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.
-
- Livecode Opensource Backer
- Posts: 9388
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Rehashing Switch
When I go shopping, when I don't find the first thing on the shopping list I don't pack upa more natural language construct
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?
-