Attached Types and Their Application to Three Open Problems of Object-Oriented Programming

  • Bertrand Meyer
Part of the Lecture Notes in Computer Science book series (LNCS, volume 3586)


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 development 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 provide a small improvement over previously proposed techniques; and how to provide a “once per object” facility, permitting just-in-time evaluation of certain object properties.

The solution relies on a small extension to the type system involving a single symbol, the question mark. The idea is to declare certain types as “attached” (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 addition, the design replaced an existing type-querying construct by a simpler one.)

The mechanism is completely static: all checks can be performed by compilers 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.


Formal Argument Validity Rule Program Text Expanded Type Creation Instruction 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    Barnett, M., Leino, R., Schulte, W.: The Spec# Programming System. In: Barthe, G., Burdy, L., Huisman, M., Lanet, J.-L., Muntean, T. (eds.) CASSIS 2004. LNCS, vol. 3362, pp. 49–69. Springer, Heidelberg (2005)CrossRefGoogle Scholar
  2. 2.
    Chambers, C., et al.: papers on the Self language, at,
  3. 3.
    Fähndrich, M., Leino, R.: Declaring and Checking Non-null Types in an Object-Oriented Language. In: OOPSLA 2003, SIGPLAN Notices, November 2003, vol. 38(11), pp. 302–312. ACM, New York (2003)Google Scholar
  4. 4.
    ECMA Technical Committee 39 (Programming and Scripting Languages) Technical Group 4 (Eiffel): Eiffel Analysis, Design and Programming Language, Draft international standard (April 2005)Google Scholar
  5. 5.
    Meijer, E., Schulte, W.: Unifying Tables, Objects, and Documents. In: Proc. DP-COOL (2003), also at,
  6. 6.
    B. Meyer: Eiffel: The Language, Prentice Hall (revised printing, See also Bertrand Meyer (1990) (revised printing 1991), See also [12]Google Scholar
  7. 7.
    Meyer, B.: Reusable Software: The Base Object-Oriented Component Libraries. Prentice Hall, Englewood Cliffs (1994)Google Scholar
  8. 8.
    Meyer, B.: Object-Oriented Software Construction, 2nd edn. Prentice Hall, Englewood Cliffs (1997)zbMATHGoogle Scholar
  9. 9.
    Meyer, B.: reference [18], ch.17: TypingGoogle Scholar
  10. 10.
    Meyer, B.: Prelude to a Theory of Void. Journal of Object-Oriented Programming 11(7), 36–48 (1998)Google Scholar
  11. 11.
    Meyer, B.: reference [8], ch. 30: Concurrency, distribution, client-server and the Internet Google Scholar
  12. 12.
    Meyer, B.: Standard Eiffel, new edition of [6], in progressGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2005

Authors and Affiliations

  • Bertrand Meyer
    • 1
    • 2
  1. 1.ETH Zurich 
  2. 2.Eiffel Software 

Personalised recommendations