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, dunb...@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 <p...@mollysrevenge.com> > To: How to use LiveCode <use-livecode@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@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@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
