Contracts for First-Class Classes

Abstract

First-class classes add expressive power to class-based objectoriented languages. Most importantly, programmers can abstract over common scenarios with first-class classes. The addition of behavioral software contracts to a language with first-class classes poses significant challenges, however. In this paper, we present the first contract system for a programming language with first-class classes. The design has been implemented for PLT Scheme, which supports first-class classes and which implements mixins and traits as syntactic sugar. We therefore expect that our experience is also useful for languages with native mixins and/or traits. First-class Classes and ContractsOver the past couple of decades, programming language designers have repeatedly demonstrated the usefulness of operations on classes. For example, Bracha and Cook [7] distilled and formalized the Flavors notion of mixins 1 [37]. Roughly speaking, mixins in a single-inheritance language are functions from classes to classes, adding fields and methods to the given class. Since then mixins have been the subject of numerous studies [1,3,9,17,33] [29,41], and PLT Scheme [15] take the final step and turn classes into first-class values. In such a world, the evaluation of an expression may produce a class. Methods or functions may consume and produce classes. Classes may store classes in fields. And most importantly, the super-class designator in a class is just an expression, meaning the super-class is computed at runtime. Equipped with this power, a programmer can add mixins and traits as "syntactic sugar" [16] but even better, a programmer can explore entirely new ways of organizing class-based programs.PLT Scheme, like Eiffel [36] and many other object-oriented languages [5, 8, 21-24, 26, 31, 32, 36, 40], also comes with a contract system. A contract [6] is a logical assertion that governs the flow of values between distinct components. The compiler and the run-time system cooperate to monitor contracts so that they can issue an informative report when values fail to respect a contract. In PLT Scheme, a report on a contract violator both explains the nature of the violation and pinpoints the violator.Extending contracts to first-class classes poses significant challenges. First, it demands a language for specifying contracts for 1 The concept of mixins first appeared in H. I. Cannon's 1979 unpublished paper "Flavors: A non-hierarchical approach to object-oriented programming," an MIT technical report in draft.classes as values. Second, when classes are first-class values, their separate roles as sources of new objects and as containers for reusable code requires rather different forms of specification than those of Eiffel [36] or even something as general as JML [27]. Third, adding contracts to first-class classes demands an implementation strategy that affects the performance of classes without contracts. Finally, PLT Scheme in particular also mixes conventional inheritance and Beta-style inheritance, complicating the addition of contracts...

Expressing contract monitors as patterns of communication

“…$15.00. http://dx.doi.org/10.1145/0.0 tions [4,15,16], language integration accommodating existing semantics [6,11,19,22], and new forms of contracts [1,11,18,20,32]. Contracts are now available in a broad range of production systems.…”

Hierarchical Modeling of Complex Internet of Things Systems Using Conceptual Modeling Approaches

“…These contracts monitor the program execution on the basis of the constraints defined by the programmer. Contract systems are habitually used in object-oriented programming languages [103]. For the sake of programming, the contracts may be written for first-order functions or higher order components for checking the truth of the claims made for the flow of values in a program.…”

Manifest Contracts for Datatypes

“…Dynamic verification is possible due to executability of contracts-the runtime system can confirm that a contract holds by evaluating it. Since Eiffel advocated "Design by Contracts" [25], there has been extensive work on dynamic contract verification [33,20,11,12,43,38,8,6,7,39]. Dynamic verification is easy to use, while it brings possibly significant run-time overhead [12] and, perhaps worse, it cannot check all possible execution paths, which may lead to missing critical errors.…”