A behavioral notion of subtyping

Abstract

The use of hierarchy is an important component of object-oriented design. Hierarchy allows the use of type families, in which higher level supertypes capture the behavior that all of their subtypes have in common. For this methodology to be effective, it is necessary to have a clear understanding of how subtypes and supertypes are related. This paper takes the position that the relationship should ensure that any property proved about supertype objects also holds for its subtype objects. It presents two ways of defining the subtype relation, each of which meets this criterion, and each of which is easy for programmers to use. The subtype relation is based on the specifications of the sub- and supertypes; the paper presents a way of specifying types that makes it convenient to define the subtype relation. The paper also discusses the ramifications of this notion of subtyping on the design of type families.

Modular type checking of anchored exception declarations

“…Just like normal return types in statically typed object-oriented languages, anchored exception declarations follow the principle of behavioral subtyping [22], which is also known as the Liskov Substitution Principle. After all, both the exceptional and normal return types of a method are postconditions that are enforced by the type system.…”

Compositionality and Refinement in Model-Driven Engineering

“…Whether this amounts to a violation of the substitivity condition of Liskov and Wing [13]Let P (x ) be a property provable about objects x of type T . Then P (y) should be true for objects y of type S where S is a subtype of T .…”

Checking Framework Interactions with Relationships

“…The need for Σ u may seem surprising, but the rationale behind it is that framework constraints do not always adhere to behavioral subtyping [6]. Consider analyzing the DropDownList constraint on the code below: Since list is of type ListControl, the trigger clause of the first constraint in List.…”