COMP313A Programming Languages

1
COMP313A Programming Languages

• Object Oriented
• Progamming Languages (1)

2
Lecture Outline

• Overview
• Polymorphism
• Inheritance and the Type System
• Polymorphism and Strong Typing

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
Overview

• Non pure object oriented programming languages
• provide support for object oriented programming
• not exclusively object-oriented
• C, Ada 95, CLOS

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 cant tell which method to invoke
  until run-time
• Eiffel, C, Java restrict polymorphism
• static type checking

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
Complex z, w z new Complex (1, 2) w new
Complex (-1, 1) z z.add(w) z
z.add(w).multiply(z)
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
furniture
chair
table
desk
lounge chair
sofa
dining table

• Relationship amongst the components
• Use of inheritance
• Sublasses versus subparts

10
closed figure
polygon
ellipse
triangle
rectangle
circle
square

• Relationship amongst the components
• Use of inheritance
• Sublasses versus subparts

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
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
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
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
class stack public void push(int,
item)elementstop item int pop
() return elements--top private
int elements100 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-gtpop()
16
stack sp new stack counting_stack csp new
counting_stack sp csp // okay csp sp
// statically cant tell
Why shouldnt csp be allowed to point to an sp
object?
C strong type system
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
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
COMP313A Programming Languages

• Object Oriented
• Progamming Languages (2)

20
Lecture Outline

• The Class Hierarchy and Data Abstraction
• Polymorphism
• Polymorphism and Strong Typing

21
furniture
chair
table
desk
lounge chair
sofa
dining table
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
class stack public void push(int,
item)elementstop item int pop
() return elements--top private
int elements100 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-gtpop()
24
stack sp new stack counting_stack csp new
counting_stack sp csp // okay csp sp
// statically cant tell
Why shouldnt csp be allowed to point to an sp
object?
C strong type system
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
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
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
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
  parents definition

29
COMP313A Programming Languages

• Object Oriented
• Progamming Languages (3)

30
Lecture Outline

• Polymorphism and Strong Typing

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
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
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
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
  parents definition

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-gtpush() //stackpush csp-gt
push() //counting_stackpush sp csp
//okay sp -gt push() //which push?
dynamic or static binding
36
Type System

• behavioural equivalence
• basef(x) maybe replaced with derivedf(x)
  without risking any type errors
• identical signatures

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
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
Polymorphism Strong Typing

• Substitutability
• impose some restrictions on the use of
  inheritance
• Type extension
• the derived class can only extend the type of
  base class
• cant modify or hide any member variables or
  functions
• Ada 95
• problem is it rules out dynamic binding (dynamic
  dispatch) completely

40
Polymorphism Strong Typing

1. Overriding of member functions

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
Polymorphism Strong Typing

• under what conditions is it possible for a use of
  a square object to substitute the use of a
  polygon object,
• i.e. p-gt 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?

42

Polymorphism Strong Typing

• 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

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

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-gtfnc(v1)
// okay if b is base but what if it is
derived
45
Polymorphism Strong Typing

• 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

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
root
child2
child1
grandchild
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
Protected Members
class stack public void push(int,
i)elementstop I int pop ()
return elements--top private
int elements100 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-gtpop()
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)elementstop I int pop ()
return elements--top protected
int top 0 private int
elements100 class counting_stack public
stack public int size()return top
//return number of elements on stack
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
Friends
class Matrix class Vector float
v4 friend Vector operator (const Matrix,
const Vector) class Matrix Vector
v4 friend Vector operator (const Matrix,
const Vector)
53
Vector operator (const Matrix m, const Vector
v) Vector r for (int i 0 i lt 4
i) r.vi 0 for
(int j 0 j ,4 j) r.vi
m.vi.vj v.vj return r