0 > 1. So is empty

[dunbarx]

Ugh.

In a button script:

Code: Select all

on mouseUp
   get "1" & comma & "2" & comma & "3" & comma & comma & "4"
   answer getPlate(it)
end mouseUp

function getPlate it
   switch
      case item 2 of it > 1
         put  "item2" & return after temp
      case item 3 of it > 1
         put "item3" & return after temp
      case item 4 of it  > 1
         put "item4" & return after temp
         put item 4 of it * 10 into tenTimesItem4
      case item 5 of it  > 1 
         put "item5" & return after temp
   end switch
   return temp & return & return & "Item 4 times ten=" && tenTimesItem4
end getPlate

I am having issues with item 4 of the string in the variable it. The fourth item is empty, I believe, and 10x the value of that item gives, what do you know, just for the #@&*% of it, "0".

Step through the code if you dare. Could be me, of course.

If I transform the function into an "if" construction, all works just fine.

Craig Newman

[Klaus]

HI Craig,

does it make a difference if you add a BREAK after each case?


Best

Klaus

[dunbarx]

Klaus.

Code: Select all

does it make a difference if you add a BREAK after each case?

I do not want any breaks, rather, to build each element that passes the ">0" test, accumulating the values that do so. If I break out of the progression, I would never reach that fourth problematic instance.

I did enter this in the "Experienced Developer" section.

Craig

[bn]

Craig,

I stay clear of switch with conditionals as they confuse me.
I tried you code and then added some different conditions.

It seems that without a break statement once one of the conditions is true this overrules the rest of the conditonals.
If I read the dictionary I could find something in that word-cloud to that effect, not sure.

Try this

Code: Select all

on mouseUp
   get "1" & comma & "2" & comma & "3" & comma & comma & "4"
   answer getPlate(it)
end mouseUp

function getPlate it
   switch
      case (item 2 of it < 1)
         put  "item2" & return after temp
         
      case item 3 of it < 1
         put "item3" & return after temp
         break
      case item 4 of it  = ""
         put "item4" & return after temp
         put item 4 of it * 10 into tenTimesItem4
      case item 5 of it  < 1 
         put "item5" & return after temp
   end switch
   return temp & return & return & "Item 4 times ten=" && tenTimesItem4
end getPlate

at least conditionals are considered, but as I said above (here item 4) once a condition is true the rest is also executed.

Kind regards

Bernd

[FourthWorld]

The Dictionary entry for the "break" control structure includes:

If no break appears, LiveCode executes each set of statements in the following case sections, whether or not the condition in the case is true. This means that if you leave out the break control structure, more than one case in the switch statement may be executed. Occasionally, this is desirable, but usually you should include the break control structure at the end of each case, to ensure that only one set of statements is executed.

[dunbarx]

@Klaus. Maybe your sunglasses were more appropriate than I first thought.

@Richard.

Well. You know, I never checked the dictionary. I just assumed it was a bug, because I thought that what you see is what you get. Hah.

I consider this at the very least a wrong-headed implementation of an otherwise wonderful construct.

It is well known that a break line after any case statement (or string of cases) exits the construct. Well and good. But it is horrifying to me that:

Code: Select all

case 2 > 1
  cheer
case 2 > 5000
  giveUp

will execute both cases, regardless of their verity, just because none have a break line. I guess my method of running successive tests is not viable at all, as I thought that each case would fire on its merits alone. I just never built it this way until I experimented in a project .

So you can only ever fire one case (or case string). Really??? Awful.

Don't tell me this is a feature.

I have to go backwards to if-then, where you do get what you see, even though switch constructions are far more direct, readable and maintainable.

Did I mention I hate this?

Craig

[bn]

Hi Craig,

after your examples I now think of case statements with conditionals as logical OR operations.
This helps me understand as to why following the first case that resolves to true the rest of case statements (without break) is also executing.

So your example helped me. Thank you for that.

@Richard Thanks for quoting the dictionary, I guess I was too tired to see the clear statement pertaining to Craig's case. I guess I find code examples easier to follow...

Kind regards
Bernd

[Klaus]

Hi Craig,

...
I did enter this in the "Experienced Developer" section.

so what?


Best

Klaus

[jacque]

This is how switch structures work in all languages universally. If there's no break, the following clause executes. Switch is not a direct replacement for if/then, though sometimes you can use it that way.

You can sort of think of it this way :

Switch with breaks = several if/else if clauses
Switch without breaks = series of if/end if clauses

[dunbarx]

Jacque.

I filed an enhancement request in the QCC (15746). I do not expect much to come of it.

When you say:

Switch without breaks = series of if/end if clauses

I still see this as not quite applicable, my issue bing that the conditional ascribed to each "case" instance is simply ignored if an earlier instance fires. A series of if-end if clauses each lives or dies on its own conditional merits. As they should.

It is that which irks me. I can learn to live in the real world. But as I mentioned in the request, I believe a great deal of potential functionality is being left on the table. I simply assumed that power and flexibility naturally lay in the structure of "switch" and its case statements per se, with "breaks" inserted as additional (optional) control elements. That is what should be.

Nobody ever needed, or wanted, this before?

Craig

[jacque]

My analogy is imperfect so I'll retract it. But the idea still stands: that's how switch statements work. Without a break, every following case statement will execute until a break is encountered or the switch construct ends. If a later case is applicable, it will overwrite any previous case.

I previously said the behavior is common to all languages but I just looked at Wikipedia and I see that's not true. Some languages do what you want. Others use LC's behavior, which allows for fallthrough, which is a handy feature that I've used more than once. See:

https://en.wikipedia.org/wiki/Switch_statement

Particularly the "fallthrough" section.

[FourthWorld]

While the code in the OP works as the Dictionary describes, I'm not sure the implementation is best. After all, the block in question about item 4 leads with a case that evaluates to false, so while I would expect all others to fall through I would not intuitively expect that case to fire.

Submitting an enhancement request to change it may cause others' code to break, but leaving it as-is risks confusing the new generation of scripters accustomed to more intuitive flow.

Hmmm...what to do....

[dunbarx]

Richard,

I mentioned legacy code, not thinking anyone ever had reason not to include "break" lines with every case instance. Now it turns out that Jacque has indeed worked with this before.

Typical of her.

So I do not expect an enhancement. I assume nobody in Scotland is prepared to create a new global property, "the fallThrough".

Craig

[jacque]

I mentioned legacy code, not thinking anyone ever had reason not to include "break" lines with every case instance. Now it turns out that Jacque has indeed worked with this before.

Typical of her.

LOL. I'm probably not the only one. Consider a situation where a user can choose from several animal pictures:

Code: Select all

 switch pChoice
    case "parrot"
    case "sparrow"
    case "hummingbird"
      go cd "bird"
      break
    case "dog"
    case "cat"
    case "mouse"
      go cd "mammal"
      break
    case "snake"
    case "lizard"
      go cd "reptile"
      break
    default
      go cd "index"
  end switch

[FourthWorld]

I assume nobody in Scotland is prepared to create a new global property, "the fallThrough".

More fun if we follow the HyperTalk convention of prefixing global props that default to false with "dont", so how about "dontUnconditionallyFallThrough".