Extend switch .. case statement for Object types and simple expressions

[Ulf Zibis]

Am 20.05.2009 00:44, Joe Darcy schrieb:
> Hello.
>
> Catching up on comments.
>
> On 03/30/09 11:31 AM, Ulf Zibis wrote:
>> AUTHOR(S): Ulf Zibis, Cologne, Germany
>>
>> OVERVIEW
>> FEATURE SUMMARY: Extend switch .. case statement for Object types and 
>> simple expressions.
>> MAJOR ADVANTAGE:
>> - Increases readability of source in concurrence to if .. else if .. 
>> else syntax.
>> - Sophisticated jumps.
>> MAJOR BENEFIT:
>> Stop some programmers escaping to some modern scripting language.
>> MAJOR DISADVANTAGE:
>> Programmers from other languages, especially C, may be confused about 
>> such rich syntax.
>>   
>
> I'm also a bit confused over what exactly is being proposed; it does 
> feel to me to be a rather aggressive change to switch.

Yes, fulfilling all given examples would be a rather aggressive change
to switch.

But you could start from example (1), and stop, where the change seems
to be too radical.
Confusing examples ?
Can you please be mor specific, which examples are confusing for you,
and in which way.

-Ulf


>
> -Joe
>
>> EXAMPLES
>> SIMPLE EXAMPLE:
>> (1):
>>     switch( myObject) {
>>         case CONSTANT1 : doSomething(); break;
>>         case CONSTANT2 : doSomethingElse(); break;
>>         default : doSomethingDefault();
>>     }
>> (2):
>>     switch( myString) {
>>         case equals("red") : stop(); break;
>>         case equals("green") : go(); break;
>>         default : openYourEyesForCrossingTraffic();
>>     }
>> (3):
>>     switch( myString) {
>>         case equalsIgnoreCase("RED") : sureStop(); break;
>>         case equalsIgnoreCase("GREEN") : sureGo(); break;
>>         default : beAwareOfPoliceWachtingYou();
>>     }
>>
>> ADVANCED EXAMPLE:
>> (1):
>>     switch( primitiveInt) {
>>         case == 10 : doOnlyIf10(); // alternative syntax for 'case 10:'
>>         case < 10 :
>>         case >= 20 : break;
>>         default : doOnlyInRange();
>>     }
>> (2):
>>     switch( primitiveInt) {
>>         case (>= 10 && < 20) : doOnlyInRange();
>>         default : throw new Exception("Out of range");
>>     }
>> (3):
>>     switch( myString) {
>>         case contains("foo") : doSomething(); break;
>>         case regionMatches(true, 2, otherString, 4, 6) : 
>> doSomethingElse(); break;
>>         default : doSomethingDefault();
>>     }
>> (4):
>>     switch( myString.equals()) { // alternative: myString.equals(..)
>>         case "foo" : foo(); break;
>>         case "bar" : bar(); break;
>>         default : dontCare();
>>     }
>> (5):
>>     switch( className.startsWith("String", ..)) { // alternative: 
>> className.startsWith("String", ?)
>>         case 0 : doForSimpleName(); break;
>>         case 9 : doForFullName(); break;
>>         default : canNotDecide();
>>     }
>> (6):
>>     switch( anyObjectOrPrimitive instanceof) { // note, that casting 
>> is solved implicit
>>         case boolean, byte, ... float : break; // Don't do anything
>>         case double : forDouble(anyObjectOrPrimitive);
>>         case HashMap :
>>         case TreeMap : forPlattformMap(anyObjectOrPrimitive); break;
>>         case Map : forOtherMap(anyObjectOrPrimitive); break;
>>         default : forObject(anyObjectOrPrimitive);
>>     }
>> (7):
>>     switch( some_lethargic_function_we_cant_call_much().equals(..) ) {
>>         case "this":
>>         case "that":       this_or_that(); break;
>>         case "bigjump":    big();    // fall
>>         case "jump":       jump(); break;
>>         case "secondlastchance":
>>         case "lastchance": last_chance(); break;
>>         default:           do_default();
>>     }
>> .. as replacement for:
>>     String sSomeString = some_lethargic_function_we_cant_call_much();
>>     if( sSomeString.equals( "this" ) || sSomeString.equals( "that" ) )
>>         this_or_that();
>>     else if( sSomeString.equals( "jump" ) || sSomeString.equals( 
>> "bigjump" ) )
>>     {
>>         if( sSomeString.equals( "bigjump" ) )
>>             big();
>>         jump();
>>     } else if( sSomeString.equals( "secondlastchance" ) ||
>>             sSomeString.equals( "lastchance" ) )
>>     {
>>         last_chance();
>>     } else do_default();
>>
>> ALTERNATIVES:
>>     switch( myString) {  // note the '.', I personally would prefer 
>> this alternative!
>>         case .equals("red") : stop(); break;
>>         case .equals("green") : go(); break;
>>         default : openYourEyesForCrossingTraffic();
>>     }
>>     switch( primitiveInt) {  // note the '.'
>>         case (. >= 10 && . < 20) : doOnlyInRange();
>> //        case (? >= 10 && ? < 20) : doOnlyInRange(); // alternative
>>         default : throw new Exception("Out of range");
>>     }
>>
>>
>> DETAILS
>> SPECIFICATION:
>> The new syntax should be interpreted as
>>     switch ( leftExpressionPart ) {
>>         case rightExpressionPart1 :
>>         case rightExpressionPart2 :
>>         ...
>>         default :
>>     }
>> The result of entire expression should be boolean type.
>> There is shortcut for:
>>     leftExpressionPart: intVariable
>>     rightExpressionPart: == intLiteral
>> (the '==' could be ommitted.)
>>
>> COMPILATION:
>> Compiler could first pre-compile to appropriate if..then..else syntax.
>> Bytecode would not be affected, but in special cases it could be more 
>> compact, if noted pre-compilation would be replaced by sophisticated 
>> optimization.
>> TESTING:
>> Compiler byte-code results for new syntax should be same than from 
>> equivalent hand-coded legacy if..then..else syntax
>> . Exception: sophisticated optimization.
>> LIBRARY SUPPORT: No supporting libraries are needed for the feature?
>> REFLECTIVE APIS: There should not be any affection to reflection API.
>> OTHER CHANGES: No.
>> MIGRATION:
>> No refactoring is needed to stay compatible.
>>
>> COMPATIBILITY
>> BREAKING CHANGES:
>> No previously valid programs are now invalid.
>> ... but ATTENTION:
>> If proposals from some other guys regarding "Strings in switch" would 
>> be taken into JDK 7, there won't be any compatible way to implement 
>> my more general proposal in future version of JDK !!!
>> --> So switch .. case statement should compare for IDENTITY if not 
>> syntactically determined otherwise.
>> --> compare for EQUALITY would also break semantic of existing switch 
>> .. case statement.
>> EXISTING PROGRAMS:
>> Source and class files of earlier platform versions interact with the 
>> feature without any notice.
>>
>> REFERENCES
>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000001.html 
>>
>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000213.html
>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html
>> http://forums.java.net/jive/thread.jspa?messageID=27781&#27781
>> http://forums.java.net/jive/thread.jspa?messageID=15769&#15769
>> http://forums.java.net/jive/thread.jspa?messageID=27773&#27773
>> http://forums.java.net/jive/thread.jspa?messageID=11393&#11393
>> EXISTING BUGS:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5012262
>> URL FOR PROTOTYPE (optional):
>>
>>
>>
>>   
>
>