1.9.2 Casts and Static Type Checking
Keywords: current

Next: 1.9.3 Exceptions as Errors Up: 1.9 Loose Ends Previous: 1.9.1 Local variables

##
1.9.2 Casts and Static Type Checking

In Scheme every primitive operation dynamically checks that its arguments have the appropriate form (type) as it executes. If an operation is applied to data of the wrong form, Scheme aborts execution and prints an error message, much as Java does when an exception is thrown and not caught.

Java also performs some argument checking during program execution (run-time), but most argument checking is done statically by the compiler before a Java program executes. A Java compiler enforces a syntactic discipline on program text called static typing. The compiler uses a collection of type-checking rules to determine whether a program is well-typed or not. Programs that are not well-typed are rejected with an explanation of which rules were broken.

The type-checking rules embody simple ``common sense'' inferences and consistency checks. The rules assign a type to every program expression and subsequently check that these type assignments are consistent. A Java compiler assigns types to program expression as follows:

1. every program constant has a type specified by the language definition;
2. every program variable (field, parameter, or local variable) has the type declared in the program;
3. each method invocation has the declared return type of the method;
4. each application of an arithmetic operator (e.g., `+`, `*`) has the return type stipulated by a table in the language definition;1.7
5. each application of a relational operator and `instanceof` test has type `boolean`;
6. each conditional expression

   > test `?` consequent `:` `alternative`

   has the more general type of the consequent type and alternative;1.8 and
7. the type of any cast expression

   > T e

   is T.

Given these type assignments, a Java compiler checks their consistency by enforcing the following rules:

1. the type of the receiver of a field selection or method invocation includes the specified field or method in its signature (a list of the member headers for the class or interface);
2. the type assigned to each argument expression in a method invocation is a subtype of the declared type of the corresponding parameter;
3. the type of the right-hand side of an assignment is a subtype of the type of the left-hand-side; and
4. the type of each return expression in a method body is a subtype of the declared return type of the method.

Note that Java type checking rules do not capture the logical consequences of `instanceof` tests. As a result, Java program text often must include apparently redundant casting operations in code following an `instanceof` test.

This phenomenon is illustrated in the following simple example. Consider the following method which could be added to the `IntList` class above.

    static Object first(IntList l) {
      if (l instanceof Cons) return ((Cons) l).first;
      else throw
        new ClassCastException("first requires a non-Empty IntList");
    }

In the method, all occurrences of the parameter `l` have the same type, namely `IntList` as declared in the method header. The

> `l instanceof Cons`

test has no effect on type-checking. As a result, the occurrence of `l` preceding the field extraction operation `.first` must be explicitly converted to type `Cons` using the casting operation `(Cons)` written as a prefix in front of `l`. Since the field `.first` is not defined in the abstract class `IntList`, the definition of the method `first` does not type check if the casting operation `(Cons)` is omitted.

Applying a casting operation `( )` to a Java expression of some static object type has consequences for both program execution and compilation. First, it inserts a run-time check to confirm that the value of belongs to the type as claimed by the casting operation. Second, it converts the static type of the expression from to .

Next: 1.9.3 Exceptions as Errors Up: 1.9 Loose Ends Previous: 1.9.1 Local variables