Technical Report Number
Existing work on behavioral subtyping either ignores aliasing or restricts the behavior of additional methods in a subtype and only allows one to use invariants and history constraints in reasoning. This prevents many useful subtype relationships; for example, a type with immutable objects (e.g., immutable sequences), cannot have a behavioral subtype with mutable objects (e.g., mutable arrays). Furthermore, the associated reasoning principle is not very useful, since one cannot use the pre- and postconditions of methods. Weak behavioral subtyping permits more behavioral subtype relationships, does not restrict the behavior of additional methods in subtypes, and allows the use of pre- and postconditions in reasoning. The only cost is the need to restrict aliases so that objects cannot be manipulated through the view of more than one type.