Over the execution of programs in an object-oriented language hangs the sword of Damocles of a "void call". This talk presents a general solution to eliminate this risk. A void call is a run-time attempt to execute a typical object-oriented call, x.f (args), while x is "void" or "null", meaning that it is not attached to any object. The result will be an exception and usually abnormal execution termination -- a crash.<P>
Rather than waiting until run time to find out, it is desirable to flag any case that can trigger this event statically, as part of the compilation process, in the same way that compilers for a typed O-O language guarantee that if there is an object it will be equipped with the prope `f'. Can we extend the type system in a simple and understandable way to eliminate void calls entirely, without putting undue expressive constraints on the programmer?<P>
The mechanism presented in this talk appears to address the problem in an economical way. The solution turns out to have several other applications as well. One is to the eradication of "catcalls", another risk of crash, which follows from the application of a covariant argument typing policy. The other is to a problem of concurrent object-oriented programming: how to guarantee object locking in a simple way, but also minimally, so that object reservation occurs when and only when absolutely required.<P>
The mechanism also provides improvements over existing solutions to two other problems of object-oriented development: forcing a type on an object (type-safe casts); and lazy evaluation of object fields ("once per object").<P>
The mechanism adds only one symbol (the question mark) to the language and replaces a construct, Assignment Attempt, by a simpler one, Object Test. Most of the effect is achieved through new validity rules on existing constructs. The mechanism is part of the draft ECMA standard for Eiffel. Various examples will be presented, as well as a discussion of benefits and limitations.
