. . . . "2018-07-16" . . "The essential rationale for subtype polymorphism is adherence to the 'Open/Closed Principle' [12]: the ability to write framework code in terms of superclasses and subsequently invoke it with any subclass that exhibits 'proper subtyping' via the Liskov Substitution Principle (LSP) [11]. Formally, the LSP states that if \u00F8(t : T) is a provable property of objects t of type T, then \u00F8(s) should be true for objects s of subtype S of T. In practice, such properties have typically been those expressible via 'Design by Contract' [12], specifically preconditions, postconditions and invariants. Such abstraction via subtype polymorphism is intended to insulate against requirements change. However, when new requirements do necessitate a change of contract, the maintenance consequences can be severe. In the (typical) absence of explicit language or tool support, enforcement of proper subtyping is laborious and error-prone: contractual changes typically require manual inspection/repair of the class hierarchy to determine/address violations of the LSP."^^ . . . . . . . . . . . . "Subtype polymorphism \u00E0 la carte via machine learning on dependent types"^^ . . . . . . . . . . . . . . . . . .