JCK feedback on "Strings in Switch" proposal

[Ulf Zibis]

Am 25.05.2009 17:01, Reinier Zwitserloot schrieb:
> Creating a string switch proposal for equalsIgnoreCase reeks of 
> creating the kitchen sink language: Stuff everything into a language 
> construct. If that's a good idea, where do we stop? How about 
> comparing strings not via case insensitivity, but intended syntactic 
> meaning (where á is equal to a to is equal to ä, and ü is equal to 
> both 'u' and 'ue', etcetera - java doesn't have this method in a 
> library, unfortunately which is why this kind of comparison isn't done 
> often, but for obvious reasons, it should be used far more often than 
> it is now). You're effectively elevating the concept of a case 
> insensitive string comparison to a part of the JLS, whereas currently 
> it isn't; it's just 1 library method and 1 static comparator object in 
> the String class.

I think you have misunderstood me mentioning "string switch proposal for 
equalsIgnoreCase".

I just want to see the switch..case construct serving as general purpose 
_n-way fork_ in program flow. IMHO it's a smart syntax providing perfect 
readability.
Only for _2-way fork_ the if..else construct is smart syntax.
Additionally if..else_if..else_if.. construct has the disadvantage of 
missing fall-through facility.

The examples show just one thinkable syntax, to feed a discussion for 
alternative ideas.

I rethought my proposal and come to more general syntax:

Proposal for SYNTAX SPECIFICATION:

    switch (expression1 | booleanExpressionTemplate(?) | 
substitution_of_?) {
        case: [booleanOperator ]expression2 | substitution_of_? | 
booleanExpressionTemplate(?)
            {...}
        ...
    }
if booleanOperator is missing:
  - expression1 is primitive value  --> execute: expression1 == expression2
  - expression1 is reference       --> execute: 
expression1.equals(expression2)
  (sophisticated special case to aviod potential NPE):
  - expression1 is reference and expression2 is CONSTANT   --> execute: 
expression2.equals(expression1)


Examples for booleanExpressionTemplate(?) and it's possible substitution:
"Math.sin(?) > 0.5"  -->  foo(bar), floatVar, intVar, PRIM_CONST 
(including autoboxed Number objects)
"? >= 10 && ? < 20"  -->  foo(bar), primitiveVar, PRIM_CONS (including 
autoboxed Number objects)
"?.equals(objectExp)"  -->  foo(bar), objectVar, OBJ_CONST (allows 
objectVar to be null)
"objectExp.equals(?)"  -->  foo(bar), objectVar, OBJ_CONST (allows ? to 
be null)
"stringExp.equalsIgnoreCase(?)"  -->  string(bar), stringVar, 
STRING_CONST, "litteral"

Examples for "expression1.. [booleanOperator ]expression2" and mixed :
switch (stringExp) {
    case == STRING_CONST1 :  // compare for identity
        {...}
    case STRING_CONST2 :  // compare for equality
        {...}
    case STRING_CONST3.equals(?) :  // compare for equality, avoiding NPE
        {...}
    case STRING_CONST4.equalsIgnoreCase(?) :  // compare for equality 
ignoring case
        {...}
    case ?.subString(?.indexOf(STRING_CONST5)).startsWith(STRING_CONST6) 
:  // sophisticated
        {...}
    default:
        {...}
    }
switch (primitiveExp) {
    case == CONST1 :  // compare for equality
        {...}
    case CONST2 :  // compare for equality
        {...}
    case myList.get(3) :  // autoboxing
        {...}
    case > CONST3 :  // compare for greater than
        {...}
    case ? >= 10 && ? < 20 :  // range check
        {...}
    ...
    }


-Ulf