Lecture 10: Part 1: OO Issues

1
Lecture 10 Part 1 OO Issues

• CS 540
• George Mason University

2
Object-Oriented Languages?

• What is an OOL?
• A language that supports object-oriented
  programming
• Term is almost meaningless today Smalltalk to
  C to Java
• How does an OOL differ from an imperative
  language?
• Complex type system including inheritance and
  polymorphism.
• Object representation issues
• Resolution of names to their implementations

3

• An object is an abstract data type that
  encapsulates data,
• operations and internal state behind a simple,
  consistent interface.
• Elaborating the concepts
• Each object needs local storage for its
  attributes
• Attributes are static (lifetime of object )
• Access is through methods
• Some methods are public, others are private
• Objects internal state leads to complex behavior

The Concept
4
Implementing Object-Oriented Languages

• Two critical issues in OOL implementation
• Object representation
• Mapping a method invocation name to a method
  implementation
• These both are intimately related to the OOLs
  name space
• Object Representation
• Static, private storage for attributes instance
  variables
• Heap allocate object records or instances
• Need consistent, fast access
• Known, constant offsets
• Provision for initialization in NEW

5
Simplistic method Object Representation
Class A int b,c A z f1() f2()
For object x of type A
f1 code
f1 code
b c z f1 f2
b c z f1 f2
f2 code
f2 code
Each object gets copies of all attributes and
methods
6
Better method
Class A int b,c A z f1() f2()
For object x of type A
f1 code
b c z f1 f2
b c z f1 f2
f2 code
Objects share methods (and static attributes)
7
More typically
Class A int b,c static int d A z
f1() f2()
For object x of type A
parent class
b c z
b c z
N 2 d f1 f2
Class A
f1 code
f2 code
Objects share methods (and static attributes)
via shared class object (can keep counter of
objects N)
8
OOL Storage Layout

• Class variables
• Static class storage accessible by global name
  (class C)
• Method code put at fixed offset from start of
  class area
• Static variables and class related bookkeeping
• Object Variables
• Object storage is heap allocated at object
  creation
• Fields at fixed offsets from start of object
  storage
• Methods
• Code for methods is stored with the class
• Methods accessed by offsets from code vector
• Allows method references inline
• Method local storage in object (no calls) or on
  stack

9
Dealing with Single Inheritance

• Use prefixing of storage for objects

Class Point int x, y Class ColorPoint
extends Point Color c
self
self
x
y
c
10
Object-Oriented Languages - Dispatching

• Mapping message names to methods
• Static mapping, known at compile-time
  (Java, C)
• Fixed offsets indirect calls
• Dynamic mapping, unknown until run-time
  (Smalltalk, C with pointers)
• Look up name in class table of methods
• This is really a data-structures problem
• Build a table of function pointers
• Use a standard invocation sequence

11
Single Inheritance and Dynamic Dispatch
Class Point int x, y public void
draw() public void d2o() Class
ColorPoint extends Point Color c public void
draw() public void rev()
table
Point draw
self
Point d20
table
ColorPointdraw
self
rev
ColorPoint rev
12
Multiple Inheritance

• The idea
• Allow more flexible sharing of methods
  attributes
• Relax the inclusion requirement
• If B is a subclass of A, it need not
  implement all of As methods
• Need a linguistic mechanism for specifying
  partial inheritance
• Problems when C inherits from both A B
• Cs method table can extend A or B, but not both
• Layout of an object record for C becomes tricky
• Other classes, say D, can inherit from C B
• Adjustments to offsets become complex
• Both A B might provide fum() which is seen in
  C ?
• C produces a syntax error when fum() is used