| Code: |
| void foo(int x) {
switch (x) { case 1: // Do something for 1, 2, and 3. case 2: // Do something for 2 and 3. case 3: // Do something for 3 only. break; default: // Do something for others. } } |
This can be done in VF with GoTo Case:
| Code: |
| Sub foo x%
Select Case x% Case 1 ' Do something for 1, 2, and 3. GoTo Case 2 Case 2 ' Do something for 2 and 3. GoTo Case 3 Case 3 ' Do something for 3 only. Case Else ' Do something for others. End Select End Sub |
However, this could be a source for bugs. If we need to add more cases, we have to remember to add appropriate GoTo statements. And if the values ever have to change, we have to change them in two places. If we give a GoTo Case a non-existent Case value, it will quietly jump to Case Else.
I propose a modifier for each Case to specify the fall-through behavior of C-like languages. The modifier I'm going with for now is @Open.
I realize that it is already used by several statements -- Class, Enum, Method, and Property.
Here's the same example rewritten to use @Open Case:
| Code: |
| Sub foo x%
Select Case x% @Open Case 1 ' Do something for 1, 2, and 3. @Open Case 2 ' Do something for 2 and 3. Case 3 ' Do something for 3 only. Case Else ' Do something for others. End Select End Sub |
An additional proposal is to use the same modifier on the Select statement itself. This would cause the particular Select...Case statement's behavior to change completely to that of C-like languages. Plus, this would require a way to break out of the Select...Case statement. The most logical choice is to use Exit Select, a statement that VB.NET has, but it is almost completely useless because VB's Select...Case works almost the same as the current VF specification.
Here's the same example re-written to use @Open Select:
| Code: |
| Sub foo x%
@Open Select Case x% Case 1 ' Do something for 1, 2, and 3. Case 2 ' Do something for 2 and 3. Case 3 ' Do something for 3 only. Exit Select Case Else ' Do something for others. End Select End Sub |