2. Chair of Software Engineering Object-Oriented Software Construction Bertrand Meyer Lesson 21 Last update: 25 May 2004 Type issues, covariance and catcalls

3. Chair of Software Engineering Programming in the Large, 2004 2 What’s special about this lecture Mix of:  Fundamental concepts  Unsolved issues  Recent proposal

4. Chair of Software Engineering Programming in the Large, 2004 3 Flexibility vs. safety Expressive power (no “bondage and discipline” language) Protection against crashes and attacks

5. Chair of Software Engineering Programming in the Large, 2004 4 Typing approaches Pascal x := y Only if types of x and y are identical! Smalltalk  x.f always permitted, not static type check!  At execution time: “ Message not understood ”

6. Chair of Software Engineering Programming in the Large, 2004 5 Like Pascal in basic forms But polymorphism allows more flexible assignment rule: x := y permitted if type of y “conforms to” type of x Typed O-O languages

7. Chair of Software Engineering Programming in the Large, 2004 6 Basic type rules in typed O-O languages Eiffel, Java,.NET... In every assignment x := y (or argument passing), type of y conforms to type of x. In every feature call x.f(…) (qualified), f is an exported feature of the class of x. C++: “A little bit typed” (Casts)

8. Chair of Software Engineering Programming in the Large, 2004 7 Terminology Typed vs untyped languages More accurate:  Statically typed, vs  Dynamically typed

9. Chair of Software Engineering Programming in the Large, 2004 8 Typing is always pessimistic Invalid in Pascal: var n: INTEGER n := 0.0 if 0 > 1 then begin n := 0.0 end

10. Chair of Software Engineering Programming in the Large, 2004 9 The basic goal A programming language is statically typed if its definition includes a set of type rules, guaranteeing that no execution of a valid program will ever produce a run-time type failure. A type rule is a validity constraint involving the types associated with program elements. A validity constraint for a programming language is a boolean condition applicable to any syntactically legal program text in the language.

11. Chair of Software Engineering Programming in the Large, 2004 10 Precise definitions An object-oriented program is class-level-valid if it satisfies the following properties:  In every assignment x := y (or argument passing), type of y conforms to type of x.  In every feature call x.f(…) (qualified), f is an exported feature of the class of x. Without catcalls, any class-level-valid program would be type-safe!

12. Chair of Software Engineering Programming in the Large, 2004 11 The issue: flexibility vs safety Find a type system that:  Supports covariance and genericity  Permits full static type checking Stated differently:  Disprove the “Pierre America conjecture” that one can have at most two of polymorphic substitution, covariance, and static type checking  Fix the “holes” in Eiffel’s type system

13. Chair of Software Engineering Programming in the Large, 2004 12 A typical covariance situation

14. Chair of Software Engineering Programming in the Large, 2004 13 Original class class BOAT feature captain: SKIPPER -- Skipper assigned to this boat sail (c: SKIPPER) is -- Appoint c as captain of this boat. require c /= Void do captain := c ensure captain = c end

15. Chair of Software Engineering Programming in the Large, 2004 14 Original class (simplified) class BOAT feature captain: SKIPPER sail (c: SKIPPER) is do captain := c end ARRAYED_ BOAT STACK CAT captain sail(...) sail(...) ARRAYED_ SKIPPER STACK CAT_ SKIPPER captain

16. Chair of Software Engineering Programming in the Large, 2004 15 Heir class class CAT inherit BOAT redefine captain, sail end feature captain: CAT_SKIPPER sail (c: CAT_SKIPPER) is do captain := c end

17. Chair of Software Engineering Programming in the Large, 2004 16 Original class, using anchored type class BOAT feature captain: SKIPPER sail (c: like captain) is do captain := c end No explicit redefinition necessary for sail in CAT (see next)

18. Chair of Software Engineering Programming in the Large, 2004 17 Heir class class CAT inherit BOAT redefine captain end feature captain: CAT_SKIPPER end

19. Chair of Software Engineering Programming in the Large, 2004 18 Static typing vs. dynamic binding x.f Static typing: ensures that there is AT LEAST ONE FEATURE Dynamic binding: ensures that it is THE RIGHT FEATURE

20. Chair of Software Engineering Programming in the Large, 2004 19 Catcalls boat1: BOAT; cat1: CAT skipper1: SKIPPER; cat_skipper1: CAT_SKIPPER... boat1 := cat1... boat1.sail (skipper1) The captain of this catamaran is now a plain SKIPPER ! Might try to do captain.repair_second_hull (see next) captain (SKIPPER) (CAT) “Ticking bomb”

21. Chair of Software Engineering Programming in the Large, 2004 20 Catcalls class BOAT feature do_maintenance is do -- Something here. end feature do_maintenance is do captain.repair_second_hull end class CAT inherit BOAT redefine do_maintenance end

22. Chair of Software Engineering Programming in the Large, 2004 21 Catcall situation ARRAYED_ BOAT STACK CAT captain sail(...) sail(...) repair_second_hull ARRAYED_ SKIPPER STACK CAT_ SKIPPER captain

23. Chair of Software Engineering Programming in the Large, 2004 22 Consequences of a catcall Crash? Security attack?

24. Chair of Software Engineering Programming in the Large, 2004 23 Catcalls: source #2 — Genericity skipper_list: LIST [SKIPPER] cat_skipper_list: LIST [CAT_SKIPPER]... skipper_list := cat_skipper_list skipper_list.extend (skipper1) cat_skipper1 := cat_skipper_list.last

25. Chair of Software Engineering Programming in the Large, 2004 24 Catcalls: source #3 — Descendant hiding class RECTANGLE inherit POLYGON export {NONE} add_vertex end... end poly1 := rect1... poly1.add_vertex (...)

26. Chair of Software Engineering Programming in the Large, 2004 25 CAT Changed Availability or Type

27. Chair of Software Engineering Programming in the Large, 2004 26 Pierre America, 1990 At most two of:  Polymorphic substitution  Covariance  Static type checking

28. Chair of Software Engineering Programming in the Large, 2004 27 Previous solutions: novariance C++, Java,.NET... Eliminates the problem (obviously) Forces programmers to do the conversions themselves May result in brittle code

29. Chair of Software Engineering Programming in the Large, 2004 28 Previous solutions: contravariance Results specialized, arguments generalized Solves the problem Only problem: doesn’t match practical needs The world seems to be covariant.

30. Chair of Software Engineering Programming in the Large, 2004 29 Previous solutions: catch catcalls Generate code to check arguments Cause exception if wrong type Avoids the security issue Disadvantages:  Performance penalty in all cases  Forces issue on client!  No easy way to force client to handle exception  Exception too drastic

31. Chair of Software Engineering Programming in the Large, 2004 30 Previous solutions: Overloading Consider that redefinition creates a new variant of the routine but doesn’t obliterate the previous one. Name resolution combines dynamic binding and overloading. Semantic rules can be devised (Giuseppe Castagna, ENS Paris) Doesn’t seem compatible with goals of O-O programming

32. Chair of Software Engineering Programming in the Large, 2004 31 Previous solutions: system-level validity Considering all assignments, compute dynamic type set (DTS) of any variable x. If there is an assignment x := y, or a corresponding argument passing, all elements of DTS of y are also in the DTS of x.  No attempt at control flow analysis  Fixpoint algorithm  Helps with optimization Disadvantages:  Pessimistic  Not incremental  Difficulty of giving precise diagnostics

33. Chair of Software Engineering Programming in the Large, 2004 32 Previous solutions: class-level validity If there is an assignment x := y and y is of a different type from x, or (recursively) y is polymorphic, consider x polymorphic. Any formal routine argument is polymorphic Disallow x. r (...) if x is polymorphic and r is a CAT routine. Local information, all incremental Disadvantages:  Pessimistic  Difficulty of giving precise diagnostics

34. Chair of Software Engineering Programming in the Large, 2004 33 Recent Eiffel developments Tuples Expanded inheritance

35. Chair of Software Engineering Programming in the Large, 2004 34 Tuple types and tuples TUPLE [X, Y, Z] Denotes sequences of at least three elements, first of type X, second of type Y, third of type Z Individual tuple: [x1, y1, z1] Conformance relations TUPLE [X, Y, Z]  TUPLE [X, Y]

36. Chair of Software Engineering Programming in the Large, 2004 35 Expanded inheritance class C inherit A expanded B feature... end No polymorphism permitted: a1 := c1 -- OK b1 := c1 -- Not permitted

37. Chair of Software Engineering Programming in the Large, 2004 36 The new solution (1) Covariance etc. OK with expanded inheritance Covariance also OK with non-exported features x.f(a) -- Qualified f(a) -- Unqualified

38. Chair of Software Engineering Programming in the Large, 2004 37 The new solution (2) Allow covariant redefinition even with polymorphism! Replacement (“recast”) must be provided Also applies to generic case

39. Chair of Software Engineering Programming in the Large, 2004 38 Covariant cats class CAT inherit BOAT redefine captain, sail end feature captain: CAT_SKIPPER sail (c: CAT_SKIPPER) is recast trained_as_cat_skipper do captain := c end

40. Chair of Software Engineering Programming in the Large, 2004 39 A recast function trained_as_cat_skipper (s: SKIPPER): CAT_SKIPPER is -- Version of skipper s reborn as cat skipper require exists: s /= Void do create Result.train_skipper (s) end

41. Chair of Software Engineering Programming in the Large, 2004 40 In CAT_SKIPPER class CAT_SKIPPER inherit SKIPPER create make_from_skipper feature -- Initialization train_skipper (s: SKIPPER) is require s /= Void s.trained_as_cat_skipper do … end

42. Chair of Software Engineering Programming in the Large, 2004 41 The latest… No more recast function Use exceptions instead sail (c: CAT_SKIPPER) is do captain := c rescue … Can use c … end

43. Chair of Software Engineering Programming in the Large, 2004 42 The multi-argument case r (x: TYPE1 ; y: TYPE2; z: TYPE3) is recast transform do... end with transform (x: OLD1 ; y: OLD2; z: OLD3): TUPLE [TYPE1, TYPE2, TYPE3] is do... end

44. Chair of Software Engineering Programming in the Large, 2004 43 The generic case In C [G], if there is a routine r (x: G) it must have a recast clause!

45. Chair of Software Engineering Programming in the Large, 2004 44 Possible criticism Creates a copy What if LIST of catamarans

46. Chair of Software Engineering Programming in the Large, 2004 45 The descendant hiding case Expanded inheritance works, of course More flexibility: still under discussion

47. Chair of Software Engineering Programming in the Large, 2004 46 More work Implement Analyze benefits and disadvantages further Study real software Formalize through a mathematical model, prove Solve descendant hiding issue

48. Chair of Software Engineering Programming in the Large, 2004 47 Some tentative conclusions Flexibility can be reconciled with safety No need to choose between anarchy and “bondage and discipline” Static typing is practical Language design is needed Language design is fun Committees work! Don’t sail a catamaran unless you know how to