This kind of functionality would basically make null and void what Jochem had mentioned about SWITCH statements being faster than a series of IF-ELSEs. He had suggested that SWITCH could be faster because only a single expression needs to be evaluated whereas with the IFs, multiple expressions need to be evaluated. Adding support for variables to CASEs would negate that.
All that said, I wonder if the speed improvement is anything more than negligible. I mean, what's the largest IF-ELSE or SWITCH statement that anyone has had to write? For something with only a few options (say 2-30) I wonder if we'd really notice the speed improvement. For something with a ton of options, it'd probably be better to find a different way of doing it (kind of like what Issac was saying). -- Mosh Teitelbaum evoch, LLC Tel: (301) 625-9191 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ > -----Original Message----- > From: Rob Rohan [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 14, 2002 6:48 PM > To: CF-Talk > Subject: RE: switch-case was RE: BlueDragon (was RE: How is CFMX J2EE > implemented?) > > > Since we are on a wish list, I would rather just have the ability to use > variables in a case statement. Then you could do a hack like > > <cfscript> > myrange=""; > for(i=30; i lt 45; i=i+1){ > devnull = listAppend(myrange,i,",");l > } > </cfscript> > > <cfswitch expression="#myswitch#"> > <cfcase value="#myrange#" delimiters=","></cfcase> > ... > </cfswitch> > > there have been other instance were a variable in a case would have been a > life saver. > > > -----Original Message----- > From: Matt Robertson [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 14, 2002 3:36 PM > To: CF-Talk > Subject: Re: switch-case was RE: BlueDragon (was RE: How is CFMX J2EE > implemented?) > > > No, the ZIPs aren't common usage, but I've certainly had to deal with it a > lot. Just used them to illustrate the point. Another issue with the same > application was doing age ranges. Simple to type ''30 to 45'' > and annoying > to have to type out ''30,31,32,33...'' etc. > > What I'm curious about is whether something simple to code exists that can > do that job with reasonable performance. There's no measurable > performance > hit on the client/server app, so *someone* was able to build it > and make it > work. > > That code BTW is from a product called Superbase. Mighty > powerful RAD stuff > that no one has ever heard of. Between pathetic promotion back when the > market was still young (SB was the first native Windows DB) and Microsoft > selling Access for $99 in a field where the competition was $700... it was > never a volume player. A great tool, but not something you'd spend time > learning unless you had to. > > --------------------------------------- > Matt Robertson [EMAIL PROTECTED] > MSB Designs, Inc., www.mysecretbase.com > --------------------------------------- > > > ---------- Original Message ---------------------------------- > from: S. Isaac Dealey <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > date: Mon, 14 Oct 2002 18:20:08 -0400 > > >I should probably keep my nose out of this one. :) > > > >> Ah... this is why competition is good. > > > >> I don't have a new feature, per se, but I do have a pet > >> peeve that came about from porting an app written in > >> another language to an online CF version. > > > >> The CFCASE portion of CFSWITCH is sorely limited in its > >> ability to handle parameters. It can't do ranges, and if > >> it could it can't mix multiple parameters on the same > >> line. Look at the following case argument written in > >> another language: > > > >> SELECT CASE carval% > >> CASE 1 TO 50000:H6.VL = "500":H7.VL = "500" > >> CASE 50001 TO 100000:H6.VL = "1,000":H7.VL = "1,000" > >> CASE IS > 100000:H6.VL = "2,500":H7.VL = "2,500" > >> END SELECT > > > >What's that VB? VB's the only language I'm familiar with that uses > >select-case rather than switch-case ... and I've never seen > ranges used in > a > >case statement, although I have occasionally wished that there were a > method > >for it... There are of course, other ways to accomplish this: > > > ><cfset myarray = arraynew(1)> > ><cfset myarray[1] = 100001> > ><cfset myarray[2] = 50001> > ><cfset myarray[3] = 1> > ><cfloop index="x" from="1" to="#arraylen(myarray)#"> > > <cfset mylocalvariable = min(mylocalvariable,myarray[x])> > ></cfloop> > ><cfswith expression="#mylocalvariable#"> > > <cfcase value="1"></cfcase> > > <cfcase value="50001"></cfcase> > > <cfcase value="100001"></cfcase> > ></cfswitch> > > > >This is even assuming that there isn't a faster / easier way to > do this in > a > >formulaic manner, i.e. > > > ><cfset mylocalvariable = ceiling(myquery.mycolumn / 50000)> > ><cfswitch expression="#mylocalvariable#"> > > <cfcase value="1"></cfcase> > > <cfcase value="2"></cfcase> > > <cfdefaultcase></cfdefaultcase> > ></cfswitch> > > > >> 5 lines of code, total. While you could do this without > >> *too* much more CF code, this is a very simple example. > >> Doing U.S. ZIP code ranges, where you are selecting > >> combinations of individual ZIPs and ranges - can be coded > >> in a LOT fewer lines if you allow something like the > >> following: > > > >> <CFSWITCH EXPRESSION="#variables.ZIPCode#> > >> <CFCASE VALUE="LT 93711"> > >> ...blahblahblah... > >> </CFCASE> > >> <CFCASE VALUE="93712, 93713 TO 93940, 93950, 94086 TO > >> 95050"> > >> ...blahblahblah... > >> </CFCASE> > >> <CFCASE VALUE="GT 93940"> > >> ...blahblahblah... > >> </CFCASE> > >> </CFSWITCH> > > > >I dunno if I'd use zip-codes as an example of common usage ... GIS is a > >pretty hefty subject in and of itself. > > > >I suspect if I wanted to do something like this in CF I would > probably wind > >up using the database, structures or a 5-dimensional array ( one > dimension > >for each digit in the zip code ) ... most likely database ... I > could write > >a case statement in sql server with ranges, though that has a lot to do > with > >the cases in sql server ( not sure about other db servers ) being scalar > >expressions (?) is that the right term?... In any event, any one of the > >three solutions is liable to be more efficient than a horde of <cfif> > >statements as I think many of us may be apt to launch into, just because > the > >the structure and array solutions may not be very intuitive and the db > >solution requires sql knowledge that many of us haven't mastered. > > > > > >Isaac > >Certified Advanced ColdFusion 5 Developer > > > >www.turnkey.to > >954-776-0046 > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
