Rehashing Switch

[bogs]

Bogs.

You have never struggled with a handler where the nesting required to do what you wanted seemed, er, unseemly?

Not for the extremely simple things I have to do, *but*, if I found myself in such a dire strait, I would simply combine the two commands (if necessary). More likely than not, though, IF I needed to test every single possibility, I would use if / then (and possibly else if). I don't find IF/ then to be as unseemly as some, and I have constructed some fairly gnarly statements with that construct.

Well, gnarly by my simple standards, anyway

[dunbarx]

Bogs.

So have we all.

But as long as you understand what I am ranting about.

Craig

[SparkOut]

@Craig
I completely understand *what* you are looking for.
I completely fail to understand *why* you are looking for it.
Switch structures do what they do because they can evaluate specific cases which can include boolean conditions, this helps to streamline and clarify many use cases and avoid horrible nested if/thens.
But they can't be reduced to a serialised set of cases, without some further conditions to determine what should fire.
In which case, a serialised set of one-liner if/then tests is about the most succinct alternative. Personally I am hugely in favour of verbosity, and in almost every case I will use the long form of if.. then... end if. But in this scenario you can't improve the cognitive load, brevity and elegance of a serialised set of one-liner if/thens.
You could have something like

Code: Select all

switch
   case 1=1
      add 1 to a
      if 2=2 then add 1 to a
      break
    case 1 = 500
      add 1 to a
      break
    end switch

this would evaluate the "cases" as desired. But why would you? It's no improvement on the 3 lines of serialised if/thens

[jiml]

on mouseUp

Code: Select all

 switch
      case  1= 1
         add 1 to a
      case 1 = 5000
         add 1 to a
      case 2 = 2
        add 1 to a
   end switch
   answer a
end mouseUp

You get a "3" in "a", because without breaks to escape a particular case, all cases fire. I wanted to get a "2"

Code: Select all

 switch
      case  1= 1
         put "" into a
         add 1 to a
      case 1 = 5000
         put "" into a
         add 1 to a
      case 2 = 2
        put "" into a
        add 1 to a
   end switch
   answer a
end mouseUp

Now you get "2". But Why do that?

Jim Lambert

[dunbarx]

@Jim.

No, you get "1". Read your handler again. But that is just an example of having no "break" lines. I know how that works, and never once used it in any productive way. After all, one might as well just string the "working" lines of code directly.

Guys and gals, if a series of "one-liner if/then" statements would always do, then we wouldn't need switch statements at all. Who only uses such things? Where are the highly nested constructions I keep hearing about, and see everywhere in my own code?

So.

Nobody sees much advantage in the above "busted" variant of "Switch". I will drop the discussion; I don't really feel that the team will take this on in any, er, case.

I just like talking about LC stuff.

Craig

[FourthWorld]

I just like talking about LC stuff.

Not a bad habit to have. Not at all.

[Davidv]

Craig, I am sympathetic to the extent that I have always thought it not to read well that subsequent Case conditions are ignored once a case has triggered. However, I have become accustomed, and the current style has even been useful to me. At the moment I am adding frilly menu curtains and double-glazed picture windows to a useful little app I wrote about 17 years ago. That app happens to contain about 70 Case statements in one long Switch. Only one may fire so they all have Break, and I have arranged them in a notionally descending order of frequency (using the wet finger test rather than actual profiling). Writing them all as If..Then statements would be less readable to me, and processing every case after one that fires would be a bit of a waste. Still, I think you were proposing a new keyword such that there would be three modes: as well as exiting with Break or processing blindly as now, there could be a new one to say "continue evaluating conditionals until one is fired (all continuation options return) or they are exhausted".

Idly, I have in the past been in the habit of writing the first statement after an Answer or Ask dialog as a test for Cancel/empty before processing real options. Now, I prefer to write that as a Switch statement with the Default being the Cancel/empty case. It looks neater for reading the options, it groups the related code elements more obviously.

TLDR: I find Switch quite useful as it is. I am sympathetic to your case but will lay no money on it progressing.

David

[SparkOut]

Craig, please never stop discussing anything you want to.
Even if you can't convince people, it's always a good thing to keep talking. And sometimes failure to convince can be the fault of the unconvinced - I am sorry if I came across as dismissive. I just can't conceptualise the sort of gnarly code that would be improved by your suggestion. The 1=1 or 1=5000 cases don't convey any real problem so all I have to use is my imagination. Now my imagination can get pretty gnarly and goes amok in the woods like Jason Vorhees, so my brain has been hiding from the idea of a real use case that doesn't create complexity rather than reducing it.

[Davidv]

Craig, after considering it some more, I am willing to put in an enhancement request along the following lines, subject to your comments.
Break operates as it does today. Lack of any term operates as it does today (we cannot break any existing code).
The new term “nobreak” at the end of a Case statement has the following effects:

• execution continues with the next CASE statement

• that statement condition is evaluated and its code executed only if true

• otherwise, continue in the same fashion to evaluate subsequent CASE conditions

• If a condition fires (since the first such) then all options are open again — break, nobreak or the current default of continuing execution until end switch.

Would that do what you want?

As for the Why question, the new term allows equivalence to sequential IFs in a more readable block while adding options I might be able to exploit with a bit more thought...

[bogs]

...allows equivalence to sequential IFs in a more readable block...

See, now that I just don't get. How is 'if / then' any more or less readable than switch/case/{break | noBreak}.

I tend to read and write like I speak, and ultimately in dealing with comparisons even if I want switch / case structure, I think < If / then >.

In every logic problem I've ever seen, <if / then> can replace <switch / case> but not the reverse.

Unless your coding practice is truly terrible, how do you get that one is more readable than the other ? I know that the 'dreaded nested <if/then> will rise to the top here, something like -

Code: Select all

if x then
	if y then
		if z then
		end if
	end if
end if

...however that can be unwound just as well as going to <switch / case> can do it first of all, and secondly that is the best example of bad <if / then> structure which could be avoided to begin with.

[Davidv]

...allows equivalence to sequential IFs in a more readable block...

See, now that I just don't get. How is 'if / then' any more or less readable than switch/case/{break | noBreak}.

I agree with all of the not-quoted, in that there is no immediate problem with implementation of desired logic. For that matter, we do not really need both while and until in Repeat loops, but it makes things more convenient in terms of thinking about loop structure. By the same token, switch/case can be a more readable structure, particularly because common formatting rules set out the block structure.

Here are two logically equivalent blocks, as formatted by LC:

Code: Select all

put "freddo" into arthur
if arthur is "martha" then get "whisky"
if arthur is "freddo" then get eat("chocolate")
put it into somewhereElse

Code: Select all

 put "freddo" into arthur
 switch arthur
	case "martha"
 		get "whisky"
 		break
 	case "freddo"
 		get eat("chocolate")
 end switch
 put it into somewhereElse
 

The first one is shorter, has all of the same effects, but is less obviously a coherent code block (especially when extended into further conditionals, e.g. 5+ or 50+). The second is thus more readable. The practical effects of a nobreak statement, if any, are not yet considered. I am certain that they would not allow magical new logic. They may, however, allow existing logic in more readably coherent code blocks.

There is no way I am going to defend this option to the death.

[SparkOut]

I think I can see a "case" for an alternative "switch like" structure. If it's desirable to have such a flow, this could default to evaluating each case without a "break" but could be halted with an "exit switchthing" along the lines of "exit repeat".
The current switch structure should remain as is, though. Unless there's a global you can set before each switch structure that defaults to current behaviour, but you could "set the useNewSwitchFlow to true" like you can with useSystemDate.

[bogs]

Code: Select all

put "freddo" into arthur
if arthur is "martha" then get "whisky"
if arthur is "freddo" then get eat("chocolate")
put it into somewhereElse

Code: Select all

 put "freddo" into arthur
 switch arthur
	case "martha"
 		get "whisky"
 		break
 	case "freddo"
 		get eat("chocolate")
 		-- missing break hee hee
 end switch
 put it into somewhereElse

The first one is shorter, has all of the same effects, but is less obviously a coherent code block (especially when extended into further conditionals, e.g. 5+ or 50+).

Unless you went with a more obviously formatted <if / then> structure that looks more like a coherrent code block, such as -

Code: Select all

put "freddo" into arthur

if arthur is "martha" then 
	get "whisky"
else if arthur is "freddo" then 
	get eat("chocolate")
end if

put it into somewhereElse

- which still gives you the same result, and has equal formatting with switch case as a coherent block, but doesn't allow you to forget to add the 'break' (as your case example is missing) hee hee and still is shorter for the amount of typing (no switch / end switch / break needed).

I'm sorry, I still fail to see any great reason to prefer one to the other based on some perceived 'block reading' ability except as I said earlier, the dreaded (and almost always completely unnecessary) "complicated nested" <if / then>.

[jiml]

No, you get "1". Read your handler again

AH yes. Right you are!
The danger of posting code without actually running it!

Jim L

[richmond62]

subsequent Case conditions are ignored once a case has triggered.

Um, well, what about some sort of switch structure that alters itself?

Let us set up a rather silly example:

Code: Select all

on mouseUp
input xDATA
switch xDATA
case contains "a"
add 1 to XXX
break
case contains "1"
add 1 to XXX
break
case contains "sausages"
add 1 to XXX
end switch
end mouseUp

AND I input 'a1', I obviously want my switch to run through twice: once to catch 'a' and again to catch '1'.

So . . . how about each time a case is answered that case is commented out of the switch code?