Page 2 of 2
Re: 0 > 1. So is empty
Posted: Tue Aug 18, 2015 10:09 pm
by jacque
FourthWorld wrote: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.
Agreed, it does seem odd. I think it's like Bernd said, the structure acts like a logical OR operation.
Re: 0 > 1. So is empty
Posted: Tue Aug 18, 2015 11:15 pm
by dunbarx
Jacque.
Right. This is standard form, though here "ganged" cases all point to a single command, and break out explicitly. The "conditionals" are inherent in the parameter following each case instance.
I thought you had done what I presented, where each case may or may not fire:
Code: Select all
switch
case pChoice contains "carrot" or pChoice contains "beans" or pChoice contains "lettuce"
put "vegetable" & return after tObject
case pChoice contains "tame" or pChoice contains "houseBroken" or pChoice contains "personal"
put "pet" & return after tObject
case pChoice contains "dog" or pChoice contains "cat" or pChoice contains "mouse"
put "mammal" & return after tObject
case pChoice contains "parrot" or pChoice contains "sparrow" or pChoice contains "hummingbird"
put "bird" & return after tObject
end switch
So if you invoked this with (pseudo):
Code: Select all
put "houseBroken parrot" into pChoice
run the switch
you would get "pet bird", and nothing else.
Craig
Re: 0 > 1. So is empty
Posted: Wed Aug 19, 2015 12:18 am
by jacque
If you swap cases 2 and 3, you do get "pet bird". It appears to run through all cases after the first match. If there are no matches you get nothing.
I have used conditional cases in the past but I can't remember where, and I don't remember whether there were fallthroughs or not. I know I've never hit the issue we're discussing though. Maybe the LC team will agree with your report.
Re: 0 > 1. So is empty
Posted: Wed Aug 19, 2015 3:48 am
by dunbarx
Jacque.
The trick is not to have to order the case statements so that they perform the way you need them to. The trick is to have the condititionals determine the way things perform.
Craig
Re: 0 > 1. So is empty
Posted: Wed Aug 19, 2015 9:44 pm
by AxWald
Hi,
ever avoided "switch/ case" for this. I just don't get the way it works.
I'd expect:
- if there is a "break" in the first "true statement", it exits at it.
- if there is no "break" in a "true statement", it & all following "true statements" are executed.
(Until one has a break)
So basically:
- "break" in a "true statement" exits after execution
- no "break" means other following "true statements" are executed, until one has "break" or the loop ends.
- "false statements" are never executed.
I may be completely wrong, for sure :)
As mentioned, it confuses me - so I keep my hands off ;-)
Have fun!
Re: 0 > 1. So is empty
Posted: Wed Aug 19, 2015 10:05 pm
by dunbarx
AxWeld.
My point from the start was that, without explicit "break" lines, after a "true" evaluation, subsequent case statement conditionals which evaluate to "false" are executed as well. That seems unseemly to me.
What I assumed, and filed an enhancement request for, was that a series of case statements without breaks would fire based solely on their evaluations. In other words, you are not forced to exit the construction at the first "true" evaluation; you may continue and perhaps find others.
This may actually have gotten the attention of the team, as they have confirmed the situation, and indicated they are working on it.
We will see...
Craig