Attached Types and Their Application to Three Open Problems of Object-Oriented Programming
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.
- 2.Chambers, C., et al.: papers on the Self language, at, http://research.sun.com/self/papers/papers.html
- 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.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.Meijer, E., Schulte, W.: Unifying Tables, Objects, and Documents. In: Proc. DP-COOL (2003), also at, http://research.microsoft.com/~emeijer/Papers/XS.pdf.
- 6.B. Meyer: Eiffel: The Language, Prentice Hall (revised printing, See also Bertrand Meyer (1990) (revised printing 1991), See also Google Scholar
- 7.Meyer, B.: Reusable Software: The Base Object-Oriented Component Libraries. Prentice Hall, Englewood Cliffs (1994)Google Scholar
- 9.Meyer, B.: reference , ch.17: TypingGoogle Scholar
- 10.Meyer, B.: Prelude to a Theory of Void. Journal of Object-Oriented Programming 11(7), 36–48 (1998)Google Scholar
- 11.Meyer, B.: reference , ch. 30: Concurrency, distribution, client-server and the Internet Google Scholar
- 12.Meyer, B.: Standard Eiffel, new edition of , in progressGoogle Scholar