Background
----------

Java 5 introduced generic types to the core Java syntax. This has had
two effects. Firstly, the type-safety of code using generics is much
better. In particular, it is now possible to have type-safe generic
collections. Seccondly, it has removed the need for many explicit cast
operations. This makes the code more readable, and also cuts out yet
another source of run-time failures.

Some casting between Object types will always be required in Java.
However, generics have shown that removing the need for explicit casts
by adding language features can be a worth-while trade off between
language complexity and increased code quality.

One of the most frequent remaining cases where casts are used is when
executing a block only if an object is of a given type. A contrived
example would be:

Object item;
...
if(item instanceof String) {
  String s = (String) item;
  s.subString(2, 5);
} else if(item instanceof Number) {
  Number n = (Number) item;
  n.intValue();
} else ...

Code like this is often found in parsers and AST processors,
serialization code, and user input handling. Although sometimes it
indicates that the software has not been developed in a very OO manner,
it is in some cases unavoidable or just pragmatic.

These code blocks always follows the same highly-stylised form. There is
an if/else where each if is a test on instanceof for some class, and
then inside the if, the object is cast to that class and then used. C#
and C++ both have syntaxes to simplify this type of conditional-on-type
expression. ML-family languages tend to support this kind of expression
directly in the language as a list of alternates guarded by types using
their pattern-matching facilities. Some languages, such as NICE use
multiple dispatch (Java has single-dispatch - dispatch on object type,
and non-oo procedural langauges usually have just one method for each
identifier). The classical OO approach to working arround having single
dispatch is to use the Visitor design pattern, but this comes with
design-time overheads and can't always be retro-fitted to existing code.


The proposal
------------

The switch construct allows code to be conditionaly executed based upon
the value of an item. The value can either be an integer type or an
enum. We propose that a similar syntax be added for switching over
types. We will refer to this as typeswitch.

Object item;
...
typeswitch (x : item)
{
  case String:
    x.subString(2, 5); // use x as String
  case Number:
    x.intValue(); // use x as Number
  ...
}

The new typeswitch expression is of the form:

  typeswitch ( identifier : expression ) typeswitch_case_list

where each typeswitch_case is of the form:

  case type_name : statement

The above example typeswitch expands to this code:

Object item;
...
if(item instanceof String) {
  String x = (String) item;
  x.subString(2, 5);
} else if(item instanceof Number) {
  Number x = (Number) item;
} else ...

As every typeswitch expression can be directly converted into existing
Java expressions, we are not adding anything to the semantics of the
language. However, we are arguably producing a much cleaner syntax that
removes the need to write repetative and error-prone code.

The colon seperating the identifier and the expression in the typeswitch
has been chosen to mirror the use of the colon in the extended for loop.
It would be possible to add a new keyword 'typeswitch' to Java, but this
may cause problems. However, the syntax of typeswitch as presented here
is easy to distinguish from that of switch, so the switch keyword could
be re-used.

To avoid type-safety issues, it would be necessary to prevent typeswitch
cases from falling through, as integer and enum switches currently do.
If fall-through was supported, then the above example would eroneously
attempt to treat a String object as a Number.

There is no need for a default clause, as Object can always be added as
one of the cases. It would probably be good coding style to habitually
supply a case that matches Object that raises an exception indicating
that there is an unhandled type case.

Cases are processed from top to bottom. It is an error to have a case
where the type is incompatible with the type of the expression. For
example, if the expression has type String, it would be an error to use
any concrete class other than String and Object. However, it would be
legal to use any interface that String does or may implement.

It is an error for a case to be unreachable because a previous case will
always accept the item. This should cover a lot of user errors.


Summing up
----------

The addition of a typeswitch construct to Java could be done with
minimal impact on existing code. It would address one of the last
remaining legitimate causes of explicit casts not addressed by generics.
By using the switch keyword with the new syntax, there would be no
reason to expand the set of Java keywords.

There are the arguments agains typeswitches that I can forsee. The
semantics of a typeswitch are not the same as that for existing switch
statements (in particular, the lack of fall-through on cases). This
would tend to be an argument towards using something modelled on a
type-aware if/else construct, such as:
  if(Type identifier : expression) body
However, in the earlier discussions, this was ruled out.

Adding typeswitch may encourage developers to use switch-over-type where
polymorphism is the cleaner solution. However, some situations just
can't be handled in this manner. The visitor design pattern is a
work-arround for some of these problem cases. A typeswitch would allow
visitor-like behavior to be implemented over class hierachies that don't
have visitor support (for example, the java reflective Type hierachy).




###@###.### 2004-12-06 22:00:41 GMT