Rehashing Switch
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Livecode Opensource Backer
- Posts: 9388
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Rehashing Switch
Me: several.
I honestly don't mind, however, which word is used as long as it makes some sort of sense.
I honestly don't mind, however, which word is used as long as it makes some sort of sense.
Re: Rehashing Switch
Sorry, my day is being overwhelmed but I will do this within 24 hours, trusting that The Originator is more placid than some other -inators...
cheers
David
cheers
David
Re: Rehashing Switch
Before I request the enhancement, I wanted to make sure we were not doing anything which broke existing LC. The following is an implementation using IF...THEN and some booleans. Its operation appears to me to be wholly consistent with current documentation, plus the new Continue. I have organised it so that Default is executed when neither Break nor Continue is encountered. It would be an alternative (drop aBreakContinue in the sample code) to allow default to be included when Continue is used, being prevented only by Break. I prefer the sample organisation, no Default on either Break or Continue.
Please check the operation by entering various number combinations in response to the Ask, and let me know whether this is the desired logic. Note differences between 4, and 34 or 24. 1 and 5 are there for other normal behaviour tests.
By the way, I see it says in the Dictionary that Switch is implemented as a command in LC. Does that mean in accessible LC script rather than C++?
edit: changed "anyTrigger" from an earlier version to "aBreakContinue" to clarify intent of that part. This example, if you run it, is meant to present the logic I will request in the enhancement, not a set of code to write.
Code: Select all
on mouseUp
ask "enter 1 or more of set [12345]"
put it into caseVal
put false into triggered
put false into aBreakContinue
repeat 1
if triggered or caseVal contains "1" then
put true into triggered
answer "1, quitting with Break"
exit repeat -- existing break
end if
if triggered or caseVal contains "2" then
put true into triggered
answer "2, unconditional continuation"
end if
if triggered or caseVal contains "3" then
put true into triggered
answer "3, Continue evaluating conditions"
put false into triggered -- the new Continue part 1
put true into aBreakContinue -- Continue part 2
end if
if triggered or caseVal contains "4" then
put true into triggered
answer "4, Default will be executed if no prior Continue"
end if
if not aBreakContinue then
answer "default"
end if
end repeat
end mouseUp
By the way, I see it says in the Dictionary that Switch is implemented as a command in LC. Does that mean in accessible LC script rather than C++?
edit: changed "anyTrigger" from an earlier version to "aBreakContinue" to clarify intent of that part. This example, if you run it, is meant to present the logic I will request in the enhancement, not a set of code to write.
Last edited by Davidv on Fri Mar 26, 2021 5:17 am, edited 1 time in total.
-
- VIP Livecode Opensource Backer
- Posts: 9665
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Rehashing Switch
David.
The enhancement will not break legacy LC handlers, because there will be no change in the use of the existing keyword "break".
If this new keyword is added ( give it a 4% chance), only an updated release will support it, because if you try to insert "continue" now, LC will think you are calling a command handler of the same name, and will throw an error.
But your handler above is an "if/then" gadget. There is no issue with that control structure since the flow in that arena is always completely directed and controlled.
Craig
The enhancement will not break legacy LC handlers, because there will be no change in the use of the existing keyword "break".
If this new keyword is added ( give it a 4% chance), only an updated release will support it, because if you try to insert "continue" now, LC will think you are calling a command handler of the same name, and will throw an error.
But your handler above is an "if/then" gadget. There is no issue with that control structure since the flow in that arena is always completely directed and controlled.
Craig
Re: Rehashing Switch
Craig, thank you for commenting although my purpose in presenting that code was to check my logic and feasibility, whether my interpretation met expectations, not to represent something that I or anyone would code, nor do I imagine other than that an enhancement in a future release is needed for Continue to be available. Sorry for not making that clearer.
cheers
David
cheers
David
-
- VIP Livecode Opensource Backer
- Posts: 9665
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Rehashing Switch
David.
I meant nothing by it beyond making sure we were on the same page with "Switch" particularly.
Sure was a lot of back-and-forth about this, which, after all, was just a suggestion about making my life easier.
Craig
I meant nothing by it beyond making sure we were on the same page with "Switch" particularly.
Sure was a lot of back-and-forth about this, which, after all, was just a suggestion about making my life easier.
Craig
-
- Livecode Opensource Backer
- Posts: 9388
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Rehashing Switch
Really? Are you sure?making my life easier
I must be even more selfish than I realised, as I thought it was about making my life easier.
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Rehashing Switch
Since I'm still not quite sure what the advantage is, I may be off track here but isn't the following simpler to read? Does it do the same thing you're trying to accomplish?
I need a fuller explanation of how changing switch is advantageous. Maybe a real-world example.
Or maybe this:
Code: Select all
on mouseUp
ask "enter 1 or more of set [12345]"
put it into caseVal
put empty into tString
repeat for each char c in caseVal
switch
case caseVal contains "1"
case caseVal contains "2"
case caseVal contains "3"
case caseVal contains "4"
put c & ", Continue evaluating conditions" &cr after tString
break
default
put "default" after tString
end switch
end repeat
put tString into fld 1
end mouseUp
Or maybe this:
Code: Select all
on mouseUp
ask "enter 1 or more of set [12345]"
put it into caseVal
put empty into tString
repeat for each char c in caseVal
switch
case caseVal contains "1"
put "1, quitting with break" after tString
exit repeat
break
case caseVal contains "2"
case caseVal contains "3"
case caseVal contains "4"
put c & ", Continue evaluating conditions" &cr after tString
break
default
put "default" after tString
end switch
end repeat
put tString into fld 1
end mouseUp
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 9665
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Rehashing Switch
Jacque.
I know you have raised this point before. After all the very pertinent comments on methods of ordering things so that either control structure can be shortened and made both effective and readable, perhaps the main advantage is that one does not have to do that sort of, er, sorting at all if the new "continue" keyword is ever implemented.
This might promote laziness. I am not sure I am against that if it does no harm.
But my initial impetus to even talk about it at all came not from laziness, but from the fact that I noticed that "break" seemed to limit quite a bit of untapped power of "switch", and I saw that changing things might enhance it. Of course, one cannot just lose "break". That forces switch into another mode entirely, and had nothing to do with my original thinking.
This all came about while I was coding away, and had to do quite a bit of finagling (that sort of effort suggested in this thread as solutions) to have switch work the way I wanted. If the new way was implemented, I could have lazed back quite a bit.
Craig
I know you have raised this point before. After all the very pertinent comments on methods of ordering things so that either control structure can be shortened and made both effective and readable, perhaps the main advantage is that one does not have to do that sort of, er, sorting at all if the new "continue" keyword is ever implemented.
This might promote laziness. I am not sure I am against that if it does no harm.
But my initial impetus to even talk about it at all came not from laziness, but from the fact that I noticed that "break" seemed to limit quite a bit of untapped power of "switch", and I saw that changing things might enhance it. Of course, one cannot just lose "break". That forces switch into another mode entirely, and had nothing to do with my original thinking.
This all came about while I was coding away, and had to do quite a bit of finagling (that sort of effort suggested in this thread as solutions) to have switch work the way I wanted. If the new way was implemented, I could have lazed back quite a bit.
Craig
-
- VIP Livecode Opensource Backer
- Posts: 9665
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Rehashing Switch
Jacque and others.
The offerings that showed how switch can be ordered so as not to need a new keyword all seem to me preThought, that is, the several cases are already somewhat ordered, and so lend themselves to being, er, orderly coded.
I must stop this "er" stuff, but I do so enjoy it.
If one is working with whatever, the cases are not often so clearly compartmentalized or classified. It is then that a new keyword would shine.
And I heard somewhere that "a little analysis is worth a thousand lines of code". I believe that, but still have had many occasions where "continue" would have come is rather handy.
Craig
The offerings that showed how switch can be ordered so as not to need a new keyword all seem to me preThought, that is, the several cases are already somewhat ordered, and so lend themselves to being, er, orderly coded.
I must stop this "er" stuff, but I do so enjoy it.
If one is working with whatever, the cases are not often so clearly compartmentalized or classified. It is then that a new keyword would shine.
And I heard somewhere that "a little analysis is worth a thousand lines of code". I believe that, but still have had many occasions where "continue" would have come is rather handy.
Craig
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Rehashing Switch
That's the thing though. I've never needed anything like you suggest so I can't picture an example. That would clear things up for me.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- Livecode Opensource Backer
- Posts: 9388
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Rehashing Switch
What there may be, instead of rehashing SWITCH, is a return to working out one's sieving process
before diving into the scriptEditor . . .
-
- VIP Livecode Opensource Backer
- Posts: 9665
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Rehashing Switch
Richmond.
Craig
Yes, we have all coded happily and successfully for years. I am sure we will continue to do so, regardless of the enhancement.a return to working out one's sieving process
before diving into the scriptEditor . . .
Craig
-
- Livecode Opensource Backer
- Posts: 9388
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Rehashing Switch
Surely the point that needs to be made is that the SWITCH structure present in LiveCode is of a structured switch,
which basically consists a longish list of ELSE options.
Possibly what the OP and others are looking for is an unstructured switch statement.
which basically consists a longish list of ELSE options.
Possibly what the OP and others are looking for is an unstructured switch statement.
Re: Rehashing Switch
Please accept my sincere apologies if i grossly misunderstood the discussion, but it would 'break' it wouldn't it?
While on the face of it there's no change in the use of the break keyword, wouldn't the lack of 'break' break the fall-through from case to case (excuse the pun...) that is often intentional with switch statements?
I agree with Jacque on this - not sure one should be messing with a basic concept like 'switch' - and it won't help newcomers from other languages to find things don't work as expected either...
Why even call it a switch statement? Call it selectCase instead and implement a new flow mechanism = problem sorted