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.


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)MATHGoogle 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