Attached Types and Their Application to Three Open Problems of Object-Oriented Programming Bertrand Meyer ETH Zurich and Eiffel Software http://se.inf.ethz.ch — http://www.eiffel.com Abstract. The three problems of the title — the first two widely discussed in the literature, the third less well known but just as important for further de- velopment of object technology — are: • Eradicating the risk of void calls: x.f with, at run time, the target x not denoting any object, leading to an exception and usually a crash. • Eradicating the risk of “catcalls”: erroneous run-time situations, almost inevitably leading to crashes, resulting from the use of covariant argument typing. • Providing a simple way, in concurrent object-oriented programming, to lock an object handled by a remote processor or thread of control, or to access it without locking it, as needed by the context and in a safe way. A language mechanism provides a combined solution to all three issues. This mechanism also allows new solutions to two known problems: how to check that a certain object has a certain type, and then use it accordingly (“Run-Time Type Identification” or “downcasting”), for which it may pro- vide a small improvement over previously proposed techniques; and how to provide a “once per object” facility, permitting just-in-time evaluation of cer- tain object properties. The solution relies on a small extension to the type system involving a sin- gle symbol, the question mark. The idea is to declare certain types as “at- tached” (not permitting void values), enforce some new validity rules that rule out void calls, and validate a number of common programming schemes as “Certified Attachment Patterns” guaranteed to rule out void calls. (In ad- dition, the design replaced an existing type-querying construct by a simpler one.) The mechanism is completely static: all checks can be performed by com- pilers as part of normal type system enforcement. It places no undue burden on these compilers — in particular, does not require dataflow analysis — and can be fairly quickly explained to programmers. Existing code, if reasonably well-written, will usually continue to work without change; for exceptions to this rule, often reflecting real risks of run-time crashes, backward-compatible options and a clear transition path are available. The result is part of the draft ECMA (future ISO) standard for Eiffel. There is one and only one kind of acceptable language extension: the one that dawns on you with the sudden self-evidence of morning mist. It must provide a complete solution to a real problem, but usually that is not enough: almost all good extensions solve several potential prob- A.P. Black (Ed.): ECOOP 2005, LNCS 3586, pp. 1 – 32, 2005. © Springer-Verlag Berlin Heidelberg 2005