2005 | OriginalPaper | Buchkapitel
Attached Types and Their Application to Three Open Problems of Object-Oriented Programming
verfasst von : Bertrand Meyer
Erschienen in: ECOOP 2005 - Object-Oriented Programming
Verlag: Springer Berlin Heidelberg
Aktivieren Sie unsere intelligente Suche, um passende Fachinhalte oder Patente zu finden.
Wählen Sie Textabschnitte aus um mit Künstlicher Intelligenz passenden Patente zu finden. powered by
Markieren Sie Textabschnitte, um KI-gestützt weitere passende Inhalte zu finden. powered by
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.