Lazy Behavioral Subtyping

1996

This paper addresses the issue of giving a formal semantics to an object-oriented programming and specification language. Object-oriented constructs considered are objects with attributes and methods, encapsulation of attributes, subtyping, bounded type parameters, classes, and inheritance. Classes are distinguished from object types. Besides usual imperative statements, specification statements are included. Specification statements allow changes of variables to be described by a predicate. They are abstract in the sense that they are non-executable. Specification statements may appear in method bodies of classes, leading to abstract classes. The motivation for this approach is that abstract classes can be used for problem-oriented specification in early stages and later refined to efficient implementations. Various refinement calculi provide laws for procedural and data refinement, which can be used here for class refinement. This paper, however, focuses on the semantics of object-oriented programs and specifications and gives some examples of abstract and concrete classes. The semantics is given by a translation of the constructs into the type system F≤, an extension of the simple typed λ-calculus by subtyping and parametric polymorphism: The state of a program is represented by a record. A state predicate is a Boolean valued function from states. Statements, both abstract and concrete, are represented by predicate transformers, i. e. higher order functions mapping state predicates (postconditions) to state predicates (preconditions). Objects are represented by records of statements (the methods) operating on a record of attributes, where the attributes are hidden by existential quantification. Classes are understood as templates for the creation of objects. Classes are represented by records. Inheritance amounts to record overwriting. Subtyping and parametric polymorphism, e. g. for the parameterization of classes by types, are already present in F≤. The advantage of this semantic by translation is that it builds on the features already provided by F≤ (which are all used). Hence no direct reference to the model underlying F≤ needs to be made; a summary of the syntax and rules of F≤ is given.

2002

Software often goes through a variety of extensions during its lifetime: adding new fields or new variants to a data structure, retroactively creating new type abstractions, and adding new operations on a data structure. As characterized by the extensibility problem, it should be possible to apply any combination of these types of extensions in any order. Mainstream object-oriented languages, however, do not well support the latter two. This paper proposes two language mechanisms that facilitate extending existing type hierarchies: multimethod dispatch and retroactive abstraction. For these two mechanisms to coexist, it is necessary to allow method dispatch on parameters of interface types, which presents problems with static type-checking. We present a type-safe solution that combines the two mechanisms by limiting multimethod type checks to package boundaries and by compiling certain packages with multimethods into sealed Jar files. † Java is a registered trademark of Sun Microsystems, Inc.

1998

In the area of object-orientation there is a long-standing schism between the rigid but safe statically typed languages, and the expressive and exible but less safe \typeless" languages. Many e orts have aimed at combining the best of both. This paper presents a language mechanism which enhances the exibility and expressivity of static languages while preserving the safety properties. It is an inheritance mechanism, with standard single inheritance as a special case. It allows both compile-time and run-time construction of new classes. Moreover, it supports specialization of existing objects at run-time. This helps avoiding the combinatorial explosion in the number of classes associated with multiple inheritance, and it supports a better separation of concerns in large systems. Pre-methoding|inheritance applied to behavioral descriptors|has been used for the construction of control structures for many years, in Beta. With dynamic inheritance, pre-methoding becomes more expressive, supporting control structures as rst class values which may be constructed and combined dynamically. Even though the concept of pre-methoding is missing from most other languages, the basic idea could be applied to any statically typed object-oriented language.

ACM SIGPLAN Notices, 2003

We develop an explicit two level system that allows programmers to reason about the behavior of effectful programs. The first level is an ordinary ML-style type system, which confers standard properties on program behavior. The second level is a conservative extension of the first that uses a logic of type refinements to check more precise properties of program behavior. Our logic is a fragment of intuitionistic linear logic, which gives programmers the ability to reason locally about changes of program state. We provide a generic resource semantics for our logic as well as a sound, decidable, syntactic refinement-checking system. We also prove that refinements give rise to an optimization principle for programs. Finally, we illustrate the power of our system through a number of examples.

ACM Transactions on Software Engineering and Methodology, 2013

Code artifacts that have nontrivial requirements with respect to the ordering in which their methods or procedures ought to be called are common and appear, for instance, in the form of API implementations and objects. This work addresses the problem of validating if API implementations provide their intended behavior when descriptions of this behavior are informal, partial, or nonexistent. The proposed approach addresses this problem by generating abstract behavior models which resemble typestates. These models are statically computed and encode all admissible sequences of method calls. The level of abstraction at which such models are constructed has shown to be useful for validating code artifacts and identifying findings which led to the discovery of bugs, adjustment of the requirements expected by the engineer to the requirements implicit in the code, and the improvement of available documentation.

Lecture Notes in Computer Science, 1999

We de ne a speci cation formalism (formally, an institution) which provides a notion of dynamic type (the type which is associated to a term by a particular evaluation) and late binding (the fact that the function version to be invoked in a function application depends on the dynamic type of one or more arguments). Hence, it constitutes a natural formal framework for modeling object-oriented and other dynamicallytyped languages and a basis for adding to them a speci cation level. In this respect, the main novelty is the capability of writing axioms related to a given type which are not required to hold for subtypes, hence can be \overridden" in further re nements, thus lifting at the speci cation level the possibility of reusing code which is o ered by the object-oriented approach.

2000

This paper proposes a new calculus for expressing the behaviour of object-oriented systems. The semantics of the calculus is given in terms of operators from computational category theory. The calculus aims to span the gulf between abstract specification and concrete implementation of object-oriented systems using mathematically verifiable properties and transformations. The calculus is compositional and can be used to express the behaviour of partial system views.

Journal of Functional Programming, 1994

To illuminate the fundamental concepts involved in object-oriented programming languages, we describe the design of TOOPL, a paradigmatic, statically-typed, functional, object-oriented programming language which supports classes, objects, methods, hidden instance variables, subtypes and inheritance. It has proven to be quite difficult to design such a language which has a secure type system. A particular problem with statically type checking object-oriented languages is designing typechecking rules which ensure that methods provided in a superclass will continue to be type correct when inherited in a subclass. The type-checking rules for TOOPL have this feature, enabling library suppliers to provide only the interfaces of classes with actual executable code, while still allowing users to safely create subclasses. To achieve greater expressibility while retaining type-safety, we choose to separate the inheritance and subtyping hierarchy in the language. The design of TOOPL has been guided by an analysis of the semantics of the language, which is given in terms of a model of the F-bounded second-order lambda calculus with fixed points at both the element and type level. This semantics supports the language design by providing a means to prove that the type-checking rules are sound, thus guaranteeing that the language is type-safe. While the semantics of our language is rather complex, involving fixed points at both the element and type level, we believe that this reflects the inherent complexity of the basic features of object-oriented programming languages. Particularly complex features include the implicit recursion inherent in the use of the keyword, self, to refer to the current object, and its corresponding type, MyType. The notions of subclass and inheritance introduce the greatest semantic complexities, whereas the notion of subtype is more straightforward to deal with. Our semantic investigations lead us to recommend caution in the use of inheritance, since small changes to method definitions in subclasses can result in major changes to the meanings of the other methods of the class.

Proceeding of the 33rd international conference on Software engineering - ICSE '11, 2011

Code artefacts that have non-trivial requirements with respect to the ordering in which their methods or procedures ought to be called are common and appear, for instance, in the form of API implementations and objects. This work addresses the problem of validating if API implementations provide their intended behaviour when descriptions of this behaviour are informal, partial or non-existent. The proposed approach addresses this problem by generating abstract behaviour models which resemble typestates. These models are statically computed and encode all admissible sequences of method calls. The level of abstraction at which such models are constructed has shown to be useful for validating code artefacts and identifying findings which led to the discovery of bugs, adjustment of the requirements expected by the engineer to the requirements implicit in the code, and the improvement of available documentation.

Companion to the first International Conference on the Art, Science and Engineering of Programming, 2017