David Evans cs.virginia/~evans

1. Lecture 8: SmallTalking about Objects Herbert Klaeren: Would you agree that the object-oriented concept has superseded the abstract data type idea. And if you were to redo the CLU development right now, would it become and object-oriented language? Barbara Liskov: Well, I guess I have a lot of answers to that question. One is that I believe the most important thing about object-oriented programming is data abstraction. It happens to be expressed in a slightly different form in object-oriented languages, with the notion that the operations belong to the objects rather than to the type. But, I don't believe that's a very important difference. I believe the important idea, grouping object and operations together, is supported by both approaches. On the other hand, I am now designing an object-oriented language and it does have an inheritance mechanism and it does have a type hierarchy mechanism. And I have to say that even today I am not a hundred percent convinced about the utility of these mechanisms. But I'm thinking about it. Question and answer from History of Programming Languages II, 1993. David Evans http://www.cs.virginia.edu/~evans CS655: Programming Languages University of Virginia Computer Science

2. Menu • What is Object-Oriented Programming? • Surveys: 78 years of C++ experience, 26 years of Java experience • Elevator Speeches (scattered) • Language Features that support OOP University of Virginia CS 655

3. Stroustrup’s Answer: The problem is that there is no distinction between the general properties of any shape and the properties of a specific shape. Expressing this distinction and taking advantage of it defines object-oriented programming. subtype polymorphism? type hierarchy O-O P is expressing and taking advantage of the distinction between the general properties of any shape and the properties of a specific shape. University of Virginia CS 655

4. Can we do this in CLU? Shape = cluster [spfc_shape: type] is create, draw where spfc_shape has draw = proctype (s: spfc_shape, x: int, y: int) rep = record [shape: spfc_shape, locx: int, locy: int] create = proc (s: spfc_shape, x: int, y: int) ... end create draw = proc (s: cvt) spfc_shape$draw (s.shape, s.x, s.y) end draw end Shape University of Virginia CS 655

5. Using Shape st: Shape[Triange] = Shape[Triangle]$create (Triangle$create (3,4,5), 10, 20) sq : Shape[Quadrangle] = Shape[Quadrangle]$create (Quadrangle$create (2,4, 6, 8), 20, 50) st.draw () % syntactic sugar assumed sq.draw () s := st s := sq st and sq are different types – can’t assign them to the same variable What’s missing? University of Virginia CS 655

6. Subtype Polymorphism Shape Triangle supertype subtype C++: base class derived class Eiffel: parent descendant Java:Triangle extends Shape. shape quadrangle triangle Triangle is-a Shape. Triangle is a subtype of Shape. Triangle  Shape Subtype can be used where supertype is expected. Program should still behave as expected if subtype is implemented correctly. ([Liskov & Wing] paper formalizes what this means.) University of Virginia CS 655

7. Subsumption Shape s; … s := new Triangle (...); ... s := new Quadrangle (...); ... B subtype of type A, you can assign B to a reference of type A. University of Virginia CS 655

8. Subsumption , ST A E :S [subsumption] A E : T , Triangle  Shape A E :Triangle A E : Square University of Virginia CS 655

9. Subtyping Rules T  T [reflexive- ] T1 T2; T2 T3 [transitive- ] T1 T3 T1 T2 [struct- ] struct [ ..., f:T1, ...]  struct [ ..., f:T2, ...] (...’s must match) Structs are monotonic. Struct is a subtype if components are subtypes. (Often called covariant.) University of Virginia CS 655

10. Arrays T1 T2 [unsound-array- ] array[T1]  array [T2] as : array[Shape]; at : array[Triangle]; ... as := at; as[2] := new Quadrangle (2, 3, 2, 6); Triangle t := at[2]; Are we sure about the struct rule’s soundness? University of Virginia CS 655

11. Procedures Triangle  Shape fss = proc (Shape) returns (Shape) fts = proc (Triangle) returns (Shape) fst = proc (Shape) returns (Triangle) ftt = proc (Triangle) returns (Triangle) fts  fss ? fst  fss? ftt  fss ? fss  fts ? University of Virginia CS 655

12. How to decide? s: Shape; t: Triangle s := fss (s); t := fst (s); t := fts (t); s := fts (s); t := fss (s); t := fss (s); s := fst (s); t := ftt (s); s := ftt (s); University of Virginia CS 655

13. Procedures fss = proc (Shape) returns (Shape) fts = proc (Triangle) returns (Shape) fst = proc (Shape) returns (Triangle) ftt = proc (Triangle) returns (Triangle) fts  fss fst  fss ftt  fss fss  fts Result can be more specific (monotonic = covariant) Parameters can be less specific (anti-monotonic = contravariant) University of Virginia CS 655

14. Procedure Calls ST S1 T1 S Sr  Tr Sn Tn monotonic on results anti-monotonic on parameters University of Virginia CS 655

15. What is Object-Oriented Programming? • Programmer can define subtype relationships • Typing rules that allow subtype to be used in place of supertype (subtype polymorphism) • Type-directed method dispatch • Implementation sharing (inheritance) Speeches! University of Virginia CS 655

16. Type-Directed Method Dispatch s: Shape := new Triangle (3, 4, 5); s.draw (); Dynamic Dispatch: Calls triangle draw method Static Dispatch: Calls shape draw method University of Virginia CS 655

17. Dispatching Solutions • C++ • Supertype declares methods virtual to allow overriding • Java • Everything is overridable, unless supertype declared it final • Eiffel • Subtype uses explicit redefine clause • Which supports reuse best? • Which is safest? University of Virginia CS 655

18. Method Binding s : Shape := new Triangle (3, 4, 5); h : int := s.getHypotenuse (); s := new Quadrangle (2, 4, 3, 8); h : int := s.getHypotenuse (); // no method Dynamic Checking: First is okay, second is run-time error. Static Checking: Both are compile-time errors. Smalltalk, Dylan C++, Java, Eiffel University of Virginia CS 655

19. Implementation Reuse:Subclassing, Inheritance • Use implementation of one type to implement another type • Often use implementation of supertype to implement subtype • Commonly used OO languages confuse issue by combining subtyping and inheritance: • Eiffel – cannot separate • Java – cannot separate, can use interfaces for subtyping only • C++ - can use implementation inheritance without subtyping (private, protected inheritance) University of Virginia CS 655

20. Language Principle:Getting Defaults Right Matters • Shouldn’t require extra work to hide things, should require extra work to expose them (forgetting something should be safer) • Possible Examples: • Algol60: call-by-value requires extra work (should have been call-by-name) • Java: preventing overriding requires extra work (final) / opposite of C++ • C++: preventing subtyping requires extra work (public inheritance is default, need private to reuse implementation without subtyping) • Java access: default is package protected, need private to hide variables and methods University of Virginia CS 655

21. A Type and Class Hierarchy Shape Quadrangle Equilateral Triangle Parallelogram EquilateralTriangle Rhombus Rectangle Square University of Virginia CS 655

22. Add an attribute • Shapes should have a color and set_color method • Change Shape, Quadrangle, Parallelogram, Triangle, Equilateral, EquilateralTriangle, Rhombus, Rectangle, Square, etc. • Change Shape, others inherit new attribute and method automatically University of Virginia CS 655

23. Add is_equilateral bool Shape::is_equilateral () { return false; } bool Equilateral::is_equilateral () { return true; } University of Virginia CS 655

24. Is a Rhombus equilateral? Shape is_equilateral () { return false; } is_equilateral () { return true; } Quadrangle Equilateral Parallelogram Multiple inheritance can be tricky! Rhombus is_equilateral? University of Virginia CS 655

25. Solutions • Java, Ada95, BETA • Don’t allow it (Java: interfaces for multiple supertypes, not implementation sharing) • Pro: Safe and Simple, Con: Limits Reuse • Eiffel • Explicit renaming or hiding (error if not done) • Automated Delegation (John Viega, 29 Feb) University of Virginia CS 655

26. Smalltalk Design Principles 1 Personal Mastery:If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. Good Design:A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework. Purpose of Language: To provide a framework for communication. University of Virginia CS 655

27. Smalltalk Design Principles 2 Objects: A computer language should support the concept of "object" and provide a uniform means for referring to the objects in its universe. Storage Management:To be truly "object-oriented", a computer system must provide automatic storage management. Uniform Metaphor:A language should be designed around a powerful metaphor that can be uniformly applied in all areas. University of Virginia CS 655

28. Smalltalk Design Principles 3 Modularity: No component in a complex system should depend on the internal details of any other component. Polymorphism:A program should specify only the behavior of objects, not their representation. Factoring:Each independent component in a system would appear in only one place. Operating System:An operating system is a collection of things that don't fit into a language. There shouldn't be one. Natural Selection: Languages and systems that are of sound design will persist, to be supplanted only by better ones. University of Virginia CS 655

29. Stroustrup’s Conclusions “Object-oriented programming is programming with inheritance. Data abstraction is programming using user-defined types. With few exceptions, object-oriented programming can and ought to be a superset of data abstraction. These techniques need proper support to be effective. Data abstraction primarily needs support in the form of language features and object-oriented programming needs further support from a programming environment. To be general purpose, a language supporting data abstraction or object-oriented programming must enable effective use of traditional hardware.” University of Virginia CS 655

30. My Conclusions • Object-Oriented Programming is a state of mind. • It is difficult to reach that state of mind if your language doesn’t have a way to declare ST and the type judgment: • Other language features can help, but we aren’t yet sure what the right ones are: dynamic dispatch, implementation inheritance, mixins, automated delegation, etc. , ST A E :S [subsumption] A E : T University of Virginia CS 655

31. Analogies • Structured Programming is a state of mind. • It is difficult to reach that state of mind if your language doesn’t have structured control statements (e.g., while, for, if, blocks, procedures) • Data Abstraction is a state of mind. • It is difficult to reach that state of mind if your language doesn’t have type checking and mechanisms for restricting access University of Virginia CS 655

32. Charge • Read Wing & Liskov paper: what must be true about S and T to make ST is safe? • Continue working on projects – make sure you understand all comments • Position Paper 2 due Monday • Talk: today at 3:30, in the Rotunda: Evelyn Fox Keller, “Linking Organisms and Computers: Theory and Practice in Contemporary Molecular Biology" University of Virginia CS 655