1. 1 COMP313A Programming Languages Object Oriented Progamming Languages (1)

2. 2 Lecture Outline Overview Polymorphism Inheritance and the Type System Polymorphism and Strong Typing

3. 3 Overview of Object Oriented Programming paradigm Pure object oriented programming languages –unit of modularity is an Abstract Data Type (ADT) implementation, especially the class –Can define new classes of objects by modifying existing classes –Java, Smalltalk, Eiffel, Dylan, C#

4. 4 Overview Non pure object oriented programming languages –provide support for object oriented programming –not exclusively object-oriented –C++, Ada 95, CLOS

5. 5 Overview Pure terminology –objects are instances of classes –object has instance variables and methods local variables declared as part of the object operations which are used to modify the object –message passing smalltalk s push 5 –polymorphic – can’t tell which method to invoke until run-time –Eiffel, C++, Java restrict polymorphism static type checking

6. 6 public Class Complex { public Complex() { re = 0; im = 0; } public Complex (double realpart, double imagpart) { re = realpart; im = imagpart } public double realpart() { return re; } public double imaginarypart() { return im; } public Complex add ( Complex c ) { return new Complex(re + c.realpart(), im + c.imaginarypart()); public Complex multiply (Complex c) { return new Complex(re * c.realpart() – im * c.imaginary part(), re * c.imaginarypart() + im * c.realpart());

7. 7 Complex z, w; … z = new Complex (1, 2); w = new Complex (-1, 1); z = z.add(w); z = z.add(w).multiply(z);

8. 8 Inheritance The subtype principal –a “derived” class inherits all the operations and instance variables of its base class derived class, sub class etc base class, super class, parent class etc Single inheritance versus Multiple inheritance

9. 9 Relationship amongst the components Use of inheritance Sublasses versus subparts furniture chairtable lounge chairsofa dining table desk

10. 10 Relationship amongst the components Use of inheritance Sublasses versus subparts closed figure polygonellipse trianglerectangle circle square

11. 11 Overview Two main goals of object-oriented language paradigm are: –restricting access to the internal (implementation) details of data types and their operations –modifiability for reuse

12. 12 The Notion of Software Reuse and Independence A corollary of Data Abstraction Given a particular Abstract Data Type –Extension of data and /or operations (specialisation - subclasses) –Redefinition of one or more of the operations –Abstraction, or the collection of similar operations from two different components into a new component (multiple inheritance) –Extension of the type that operations apply to (polymorphism)

13. 13 public class Queue { // constructors and instance variables go here public void enqueue (int x) {…} public void dequeue() {…} public int front () {…} public boolean empty() {…} } public class Deque extends Queue {// constructors and instance variables go here public void addFront ( int x {… } public void deleteRear() {… } }

14. 14 Queue q; Deque d; d = new Deque(); q = d; q.dequeue() and d.queue() OK q.deleteRear() q = d; //a compile time error in Java q = (Deque) d; // downcast

15. 15 class stack{ public: void push(int, item){elements[top++] = item;}; int pop () {return elements[--top];}; private: int elements[100]; int top =0; }; class counting_stack: public stack { public: int size(); // return number of elements on stack stack s1, s2; // automatic variables stack* sp = new stack; sp->pop()

16. 16 stack* sp = new stack; counting_stack* csp = new counting_stack; sp = csp; // okay csp = sp; // statically can’t tell C++ strong type system Why shouldn’t csp be allowed to point to an sp object?

17. 17 Polymorphism polymorphic variables could refer to objects of different classes –what is the problem for a type checker How do we allow dynamic binding and still ensure type safety strong type system limits polymorphism –restricted to objects of a class or its derived classes –e.g. variables of type stack may refer to a variable of type counting_stack Strict object-oriented languages (Smalltalk, Eiffel, Java –all objects accessed through references which may be polymorphic C++ - pointers, reference variables and by- reference parameters are polymorphic

18. 18 If we do not use pointers we do not get inclusion polymorphism. But… stack s; counting_stack cs; s = cs; //okay coerce cs to a stack cs = s; //not okay

19. 19 COMP313A Programming Languages Object Oriented Progamming Languages (2)

20. 20 Lecture Outline The Class Hierarchy and Data Abstraction Polymorphism Polymorphism and Strong Typing

21. 21 furniture chairtable lounge chairsofa dining table desk

22. 22 public class Queue { // constructors and instance variables go here public void enqueue (int x) {…} public void dequeue() {…} public int front () {…} public boolean empty() {…} } public class Deque extends Queue {// constructors and instance variables go here public void addFront ( int x {… } public void deleteRear() {… } } Is Queue more abstract than Deque or vice versa

23. 23 class stack{ public: void push(int, item){elements[top++] = item;}; int pop () {return elements[--top];}; private: int elements[100]; int top =0; }; class counting_stack: public stack { public: int size(); // return number of elements on stack stack s1, s2; // automatic variables stack* sp = new stack; sp->pop()

24. 24 stack* sp = new stack; counting_stack* csp = new counting_stack; sp = csp; // okay csp = sp; // statically can’t tell C++ strong type system Why shouldn’t csp be allowed to point to an sp object?

25. 25 Polymorphism polymorphic variables could refer to objects of different classes –what is the problem for a type checker How do we allow dynamic binding and still ensure type safety strong type system limits polymorphism –restricted to objects of a class or its derived classes –e.g. variables of type stack may refer to a variable of type counting_stack Strict object-oriented languages (Smalltalk, Eiffel, Java –all objects accessed through references which may be polymorphic C++ - pointers, reference variables and by- reference parameters are polymorphic

26. 26 If we do not use pointers we do not get inclusion polymorphism. But… stack s; counting_stack cs; s = cs; //okay coerce cs to a stack cs = s; //not okay

27. 27 The Type System The subtype principle a week day is also a day –is-a relationship similarly class and sub-class –counting_stack is-a stack but…. type day = (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday); weekday= (Monday..Friday);

28. 28 The Type System need to state the conditions under which the isa relationship holds for subclasses of classes because… subclasses can hide the variables and functions or modify them in an incompatible way need to know when they are equivalent with the parent’s definition

29. 29 COMP313A Programming Languages Object Oriented Progamming Languages (3)

30. 30 Lecture Outline Polymorphism and Strong Typing

31. 31 Polymorphism polymorphic variables could refer to objects of different classes –what is the problem for a type checker How do we allow dynamic binding and still ensure type safety strong type system limits polymorphism –restricted to objects of a class or its derived classes –e.g. variables of type stack may refer to a variable of type counting_stack Strict object-oriented languages (Smalltalk, Eiffel, Java –all objects accessed through references which may be polymorphic C++ - pointers, reference variables and by- reference parameters are polymorphic

32. 32 If we do not use pointers we do not get inclusion polymorphism. But… stack s; counting_stack cs; s = cs; //okay coerce cs to a stack cs = s; //not okay

33. 33 The Type System The subtype principle a week day is also a day –is-a relationship similarly class and sub-class –counting_stack is-a stack but…. type day = (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday); weekday= (Monday..Friday);

34. 34 The Type System need to state the conditions under which the isa relationship holds for subclasses of classes because… subclasses can hide the variables and functions or modify them in an incompatible way need to know when they are equivalent with the parent’s definition

35. 35 Dynamic Binding of Calls to Member Functions a derived class can override a member function of the parent class stack* sp = new stack; counting_stack* csp = new counting_stack; sp->push(…); //stack::push csp->push(…); //counting_stack::push sp = csp; //okay sp -> push(…) //which push? dynamic or static binding

36. 36 Type System behavioural equivalence base::f(x) maybe replaced with derived::f(x) without risking any type errors identical signatures

37. 37 Polymorphism – Strong Typing Strong typing means that How can we have dynamic binding and a strong type system stack* sp = new stack; counting_stack* csp = new counting_stack; sp = csp; //allowed csp = sp; //not allowed

38. 38 Polymorphism – Strong Typing the general case: class base {…}; class derived: public base {…}; … base* b; derived* d; b = d; //allowed d = b; //not allowed The question of substitutability - ensuring is-a Can we substitute d for b always? Is this kind of polymorphism compatible with strong typing?

39. 39 Substitutability –impose some restrictions on the use of inheritance 1.Type extension –the derived class can only extend the type of base class –can’t modify or hide any member variables or functions –Ada 95 –problem is it rules out dynamic binding (dynamic dispatch) completely Polymorphism – Strong Typing

40. 40 2.Overriding of member functions Polymorphism – Strong Typing class polygon{ public: polygon (..){…} //constructor virtual float perimeter () {…}; }; class square : public polygon { public: square (..) {…} //constructor … float perimeter() {…}; //overrides the definition of //perimeter in polygon

41. 41 under what conditions is it possible for a use of a square object to substitute the use of a polygon object, i.e. p-> perimeter() will be valid whether *p is a polygon or a square object C++ the signature of the overriding function must be identical to that of the overridden function - exactly the same parameter requirements  no type violations What happens at runtime? Polymorphism – Strong Typing

42. 42 Is it possible to relax this last restriction even further but still ensuring type safety? The input parameters of the overriding function must be supertypes of the corresponding parameters of the overriden function contravariance rule The result parameter of the overriding function must be a subtype of the result parameter of the overriden function covariance rule Polymorphism – Strong Typing

43. 43 //not C++ input parameters class base { public: void virtual fnc (s1 par) {..} // S1 is the type of the formal // parameter } class derived: public base { public: void fnc (s2 par) {…} // C++ requires that s1 is identical to // S2 } base* b derived* d s1 v1; s2 v2; if (..) b = d; b-> fnc(v1); //okay if b is base but what if it is //derived

44. 44 //not C++ result parameter class base { public: t1 virtual fnc (s1 par) {…}; // s1 is the type of formal parameter // t1 is the type of result parameter }; class derived: public base { public: t2 fnc (s2 par) {…}; // C++ requires that s1 is identical to // s2 and t1 is identical to t2 }; base* b; derived* d; s1 v1; s2 v2; t1 v0; if (…) b = d; v0 = b->fnc(v1); // okay if b is base but what if it is derived

45. 45 Who uses it? Emerald uses both contravariance and covariance C++, Java, Object Pascal and Modula-3 use neither –use exact identity Eiffel and Ada require covariance of both input and result parameters Polymorphism – Strong Typing

46. 46 Issues in Inheritance Hierarchies Ada, Java and Smalltalk have a single inheritance model Java has separate interfaces and supports the idea of inheriting from multiple interfaces C++ and Eiffel have multiple inheritance What if both elephant and circus_performer have a member function ‘trunk_wag’ Diamond inheritance class circus_elephant: public elephant, circus_performer

47. 47 root child1 child2 grandchild

48. 48 Implementation and interface inheritance object oriented programming  new software components may be constructed from existing software components inheritance complicates the issue of encapsulation interface inheritance  derived class can only access the parent class through the public interface implementation inheritance  derived class can access the private internal representation of the parent class

49. 49 Protected Members class stack{ public: void push(int, i){elements[top++] = I;}; int pop () {return elements[--top];}; private: int elements[100]; int top =0; }; class counting_stack: public stack { public: int size(); //return number of elements on stack stack s1, s2; stack* sp = new stack; sp->pop()

50. 50 Protected Members implementation inheritance versus interface inheritance protected entities are visible within the class and any derived classes class stack{ public: void push(int, i){elements[top++] = I;}; int pop () {return elements[--top];}; protected int top = 0; private: int elements[100]; }; class counting_stack: public stack { public: int size(){return top;}; //return number of elements on stack

51. 51 Protected Members class C { public: // accessible to everyone protected: // accessible to members and friends and // to members and friends of derived classes only private: //accessible to members and friends only };

52. 52 Friends class Matrix; class Vector { float v[4]; friend Vector operator* (const Matrix&, const Vector&); }; class Matrix { Vector v[4]; friend Vector operator* (const Matrix&, const Vector&); }

53. 53 Vector operator* (const Matrix& m, const Vector& v) { Vector r; for (int i = 0; i < 4; i++) { r.v[i] = 0; for (int j = 0; j,4; j++) r.v[i] += m.v[i].v[j] * v.v[j]; } return r; }