argh! why can't a switch selector be a string!

[Eric Johnson]

gotta vent. it would make life so much easier if i could use a string to determine which case to call. i'm sure there is a good reason why ya can't (which is probably beyond me), but what is that reason?

[Marilyn de Queiroz]

You can use a char.

As to why, you'll probably have to ask James Gosling and his co-founders why they only allowed primitive numerics rather than Strings (or other Objects). I could guess, but ...

[Thomas Paul]

C# allows Strings.

[Anthony Villanueva]

What's wrong with if-thens?

[Jim Yingst]

If you look at the JVM Spec, there's an instruction called tableswitch which is how switch statements typically get implemented. It's a fast way of getting to a particular spot in your code based on the switch value, without doing a lot of comparisons. (It also takes more memory than multiple comparisons would, but that's usually considered a fair trade.) This mechanism works pretty well as long as you want to switch on some sort of integer value - at least, one in a reasonable range. Longs are not allowed in switch statements, because they would require too much memory to implement simply with tableswitch. Strings and other objects would be more complex, much less amenable to treating with tableswitch. I suppose you could use a tableswitch as part of a hashtable implementation which would look up the correct jump point. But Gosling and company chose to keep the JVM and compiler requirements relatively simple in this area. Restricting the types of inputs allowed in switch() means you end up using tableswitch for those situations it works well in, and you're forced to find alternatives where it wouldn't work as well.
I do think a switch statement looks better than a long series of if / else if statements, and it would be nice to have this option. I wonder how it's implemented in C# for objects? Something hashtable-based I'm guessing. I'll have to take a look at that. But generally, using if / else if works fairly well most of the time, and there are often other OO-type alternatives if this is unsatisfactory.

[Ilja Preuss]

Originally posted by Jim Yingst:
there are often other OO-type alternatives if this is unsatisfactory.

For example a Map mapping String's to instances of a Strategy.

[rom chatterjee]

If the strings you want to switch on are constant (eg Days of the week). Then define a set of constants with meaningful names and switch on those: MyConstant.VALUE

[Ilja Preuss]

Originally posted by rom chatterjee:
If the strings you want to switch on are constant (eg Days of the week). Then define a set of constants with meaningful names and switch on those: MyConstant.VALUE

Are you suggesting to switch on String constants? That doesn't work.

[Cindy Glass]

No - he is saying that you can assign integer value to represent the constant Strings and switch on the integers.

[Mr. C Lamont Gilbert]

A chain of if statements is no more difficult to code than a switch statement anyway. Whats the beef?

[Cindy Glass]

It's the aesthetics of the code .

[Steve Deadsea]

http://developer.java.sun.com/developer/bugParade/bugs/4269827.html
for why case statements can be better than ifs and why it is hard to do optimised ifs sometimes.

[Anthony Villanueva]

It's the aesthetics of the code .

Now we're getting into a pretty sensitive topic .
Personally, I find

 
void someMethod()
{
      if( /* etc */)
      {
             // etc
      }
}

more aesthetically pleasing than

 
void someMethod(){
      if( /* etc */){
             // etc
      }
}

but try convincing a programmer who thinks differently .

[Ta Ri Ki Sun]

ah but you dont have to scroll back and forth on a 17" monitor to see the code, if's are pain when nested too deep unnecessarily

[Ilja Preuss]

Originally posted by Taariq Levack:
ah but you dont have to scroll back and forth on a 17" monitor to see the code, if's are pain when nested too deep unnecessarily

But most often this is a design issue, not a syntax or formatting issue...