A curious case

[Bob Sneidar]

I think he means that he was familiar with an IDE which used switch to test for different values of a variable, and each case statement was for value of the variable. I can see it being used in that form, but it seems to me that is actually more limiting not more flexible. In that form the ONLY thing you could test for is the value of the variable. 

Bob


On Mar 2, 2011, at 4:33 PM, DunbarX at aol.com wrote:

> No, I think it can resolve any LC statement, no?
> 
> 
> put 3 into temp
> switch
> case temp < 4
> put "lessThan"
> break
> case temp = 11
> put "never see this"
> break
> end switch
> 
> 
> Craig Newman
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Peter Haworth <pete at mollysrevenge.com>
> To: How to use LiveCode <use-livecode at lists.runrev.com>
> Sent: Wed, Mar 2, 2011 6:19 pm
> Subject: Re: A curious case
> 
> 
> Switch is definitley very handy but I wish it was more flexible.  As far as I 
> can tell, the case statement can only test for equality, for example:
> 
> switch myvar
>    case begins with "xyz"
> 
> ... generates an error as does anything else other than just a straight value on 
> the case line.
> 
> I know you can do
> 
> switch
>    case myVar begins with "xyz"
> 
> ...just seems like conditions other than = would be more elegant on the case 
> line.
> 
> Pete Haworth
> 
> On Mar 2, 2011, at 3:03 PM, Bob Sneidar wrote:
> 
>> I think the switch control structure is pretty handy for this. If you put all 
> the conditions that will not require a break at the top, then the program will 
> flow down through your conditions and only execute the code inside your case 
> statements if the conditions are true. Towards the end of the switch statement 
> put the conditions that will break when met (if any). It reads much cleaner. 
>> 
>> Bob
>> 
>> 
>> On Mar 2, 2011, at 2:39 PM, Peter Brigham MD wrote:
>> 
>>> On Mar 2, 2011, at 11:26 AM, Richard Gaskin wrote:
>>> 
>>>> Andre Garzia wrote:
>>>>> I tend to  work on the same way. longer forms makes shorter understanding
>>>>> time. I'd rather write more and understand more than write faster and then
>>>>> one week from now, be completely lost in nested mazes
>>>> 
>>>> Well said.
>>>> 
>>>> And sometimes lengthy deeply-nested IFs are good candidates for a switch 
> block.
>>>> 
>>>> I once stumbled across two tips about code style that have been very 
> helpful:
>>>> 
>>>> 1. If a given function has nested IFs more than three levels deep, it may be 
> a good candidate for breaking it up into smaller functions.
>>>> 
>>>> 2. If a function is longer than can be viewed in one screen, it may be a 
> good candidate for breaking it up into smaller functions.
>>>> 
>>>> Sometimes those can't be applied for sound practical reasons, but where they 
> can oh boy does it make code more readable.
>>> 
>>> I grapple with this all the time. My status with LC is "dedicated amateur," 
> so I may not use the best practices, but.... One other consideration is breaking 
> out a chunk of code when it needs to be reusable, but this is not without 
> problems too.
>> <snip>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode