[PDF] - Chapter 13 Implemen ting the Ob ject-Orien ted P aradigm In PDF Document

SLIDE 1 Chapter 13 Implemen ting the Ob ject-Orien ted P aradigm In this c hapter w e will discuss some

f

the diculties in v

lv

ed in implemen ting those features

f

Leda that are relev an t to the

b

ject-orien ted paradigm. 13.1 Memory La y

ut

In Chapter 10 w e in tro duced the concept

f

a p

lymorphic

v ariable. That is, in an

b

ject-

rien

ted language it is p

ssible

to declare a v ariable whic h can hold a n um b er

f

dieren t t yp es

f

v alues

v

er the course

f

execution. The

nly

limiting restriction in this regard is that all suc h v alues m ust b e instances

f

classes whic h inherit from a single common ancestor class, whic h m ust b e the class used in the declaration

f

the p

lymorphic

v ariable. In Chapter 12 w e discussed some

f

the man y uses for suc h v alues. The presence

f

p

lymorphic

v ariables in tro duces a n um b er

f

in teresting problems for the language implemen tor, problems whic h are not found in the implemen tation

f

more con v en tional languages. The rst suc h dicult y w e will consider is concerned with the allo cation

f

memory space for v ariables and for v alues. In a con v en tional language, v ariables are allo cated a xed amoun t

f

space in a xed lo cation in memory ,

r

in a xed lo cation in a blo c k

f

memory called an activation r e c

r

d that is allo cated

nce

at the b eginning

f

a function in v

cation,

and released when a function terminates. Supp

se,

for example, that w e imagine a function whic h uses

ne

lo cal in teger v ariable named x, and also declares

ne

lo cal v ariable named poly whic h is a record con taining three in teger data elds. An activ ation record for suc h a pro cedure migh t lo

k

as follo ws: 1 1 In practice activ ation records also con tain space for parameter v alues, and for v arious \b

kk

eeping" 229

SLIDE 2 230 CHAPTER 13. IMPLEMENTING THE OBJECT-ORIENTED P ARADIGM x poly

third

field poly

second

field poly

first

field No w imagine that poly is not a simple record structure, but is instead a p

lymorphic

v ariable declared as b eing an instance

f

a class whic h denes three in teger data elds. The dening c haracteristic

f

p

lymorphic

v ariables w as that they can hold values that w ere generated from sub classes. So next imagine that a sub class

f

the class from whic h poly w as declared denes t w

additional

in teger data elds, and that an attempt is made to assign a v alue generated b y this sub class to the v ariable poly. The v alue

n

the righ t

f

the assignmen t con tains v e in teger data elds. The memory allo cated to poly con tains space

nly

for three in teger data elds. Simply put, the problem is that w e are trying to store more information in to a xed size b

x

than it can hold: poly

third

field poly

second

field poly

first

field ( fifth field fourth field third field second field first field The solution in Leda is to eliminate altogether the idea that a v ariable denes a xed size b

x.

2 Instead, all v ariables are in realit y p

in

ters. When a v alue is assigned to a v ariable,

nly

this p

in

ter eld is c hanged. The v alue to whic h it p

in

ts can then b e an y size whatso ev er, with no limitations b eing imp

sed

at compile time. poly

fifth

field fourth field third field second field first field Unfortunately , a negativ e consequence

f

this decision is that it naturally leads to the p

in

ter seman tics for assignmen t whic h, as w e noted at the b eginning

f

Chapter 10, can

ccasionally

b e somewhat confusing. v alues, suc h as return address elds. These details are unimp

rtan

t for

ur

discussion here. 2 Note that this is not the

nly

solution. The language C++, for example, tak es an en tirely dieren t approac h, simply slicing

the

extra elds during assignmen t.

SLIDE 3 13.2. D YNAMIC ALLOCA TION 231 13.2 Dynamic Allo cation It is common that a v alue can b e created and b

und

to a v ariable in a w a y that ensures the v alue will

utliv

e the con text in whic h it is created. This can

ccur,

for example, if a v alue is assigned to a v ariable from a surrounding con text. T

illustrate,

consider the follo wing program, whic h uses the functional v ersion

f

the list abstraction from Chapter 4: var aList : List[integer]; function escape (); begin aList := List[integer](17 , emptyList); end; The v alue created inside the function escape m ust exist ev en after the function has returned. It is for this reason that v ery few v alues created in Leda can b e allo cated in a stac k-lik e fashion, as is common in languages suc h as P ascal

r

C. Instead, all v alues in Leda are dynamically allo cated

n

a heap, and m ust b e reclaimed b y a memory managemen t mec hanism, suc h as a garbage collection system. 13.3 Class P

in

ters An imp

rtan

t prop ert y

f

p

lymorphic

v ariables is that the selection

f

whic h

f

man y p

ssible

v ersions

f

an

v

erridden function to in v

k

e in an y particular situation dep ends up

n

the actual, run-time

r

dynamic t yp e held b y suc h a v ariable, and not

n

the dened,

r

static t yp e with whic h it w as declared. Th us, it is a requiremen t

f

all

b

ject-orien ted languages that all suc h v alues p

ssess

at least a rudimen tary form

f

\self-kno wledge" concerning their

wn

t yp e, and b e able to use this kno wledge in the selection

f

a function to execute. In Leda this self-kno wledge is em b

died

in a data eld that declared in class

bject,

and th us is common to all

b

jects (see Figure 13.1). This eld is declared as an instance

f

class Class. Class Class main tains information sp ecic to eac h dened class. In particular, this information includes the name

f

the class as a string, the n um b er

f

data elds dened in eac h class (that is, the size

f

eac h instance), and a p

in

ter to the paren t class. The metho d isInstance tak es as argumen t a v alue, and returns true if the v alue is an instance

f

a giv en class (either directly

r

through inheritance). T

do

this, the function mak es use

f

the relational

p

erators, whic h ha v e b een redened to indicate the class-sub class relationship. The less-than

p

erator tak es t w

classes,

and returns true if the paren t class

f

the left argumen t,

r

an y ancestor

f

this paren t, is the same as the righ t argumen t. The default meaning

f

the equalit y

p

erator indicates whether the t w

argumen

ts (that is,

SLIDE 4 232 CHAPTER 13. IMPLEMENTING THE OBJECT-ORIENTED P ARADIGM class

bject;

var classPtr : Class; f p

in

ter describing

b

ject g ... end; class Class

f
rdered[Class];

var name : string; size : integer; parent : Class; function asString()->stri ng; begin return name; end; function less (arg : Class)->boolean; begin if self == arg then f equal, not less g return false; if parent == arg then return true; return parent <> self & parent < arg; end; function isInstance (val :

bject)->boolea

n; begin return val.classPtr <= self; end; end; function typeTest [T :

bject]

(val :

bject,

aClass : Class)->T; begin if aClass.isInstance (va l) then return cfunction Leda

bject

cast(val)->T; return NIL; end; Figure 13.1: The class p

in

ter and the class Class

SLIDE 5 13.4. SUBCLASSES AS EXTENSIONS 233 t w

classes)

are iden tically the same. As w e sa w in Chapter 12, the remaining relational

p

erators are all dened in terms

f

these t w

functions.

The function isInstance uses the abilit y to do relational tests

n

classes in

rder

to determine if an argumen t v alue is an instance

f

the receiv er class. The isInstance function is utilized in

ne
f

the more un usual functions pro vided as part

f

the standard run-time library . This function is named typeTest, and is used to p erform \rev erse p

lymorphism";

that is, to tak e a v alue declared as holding an instance

f

a paren t class, and determine whether

r

not it is, in fact, main taining a v alue generated from a giv en c hild class. The cfunction in v

k

ed to p erform the t yp e con v ersion in this situation p erforms no action, and merely serv es to foil the t yp e c hec king mec hanism. If the argumen t v alue is not an instance

f

the giv en class, then the undened v alue NIL is returned. 13.4 Sub classes as Extensions Data elds dened within a class in Leda are handled in a similar fashion to data elds in records in languages suc h as P ascal

r

C. That is, the data elds are simply catenated together in a con tiguous fashion in memory , end to end, to yield a blo c k

f

v alues whic h together constitute the state

f

the

b

ject. F

r

example, supp

se

an

b

ject represen ts an instance

f

a class A in whic h are dened three data v alues, x, y and z. W e can imagine A lo

king

something lik e the follo wing: z y x classPtr An imp

rtan

t feature

f

sub classing is that a c hild class strictly extends the n um b er

f

data elds held b y eac h instance, nev er decreases this size. F urthermore, and just as imp

rtan

tly , w e can arrange so that the lo cation

f

eac h eld inherited from a paren t class is found in the same lo cation relativ e to the start

f

the

b

ject, regardless

f

the class from whic h the instance w as generated. That is, supp

se

w e no w imagine a sub class

f

A named B whic h denes three new data elds p, q and r, and a second sub class

f

A named C whic h denes t w

elds

m and n. A v alue from eac h

f

these classes can b e imagined as lo

king

something lik e the follo wing:

SLIDE 6 234 CHAPTER 13. IMPLEMENTING THE OBJECT-ORIENTED P ARADIGM z y x classPtr instanc e

f

A r q p z y x classPtr instanc e

f

B n m z y x classPtr instanc e

f

C It is b ecause the lo cation

f

the inherited data elds are kno wn to b e xed, regardless

f

the class from whic h the items w ere generated, that the compiler is able to pro duce co de for functions dened in the paren t classes. That is, class A can dene functions whic h manipulate the three v alues x, y and z. These functions will con tin ue to

p

erate ev en if they are manipulating an instance

f

B

r

C, instead

f

an instance

f

class A. 13.5 Virtual Dispatc h T ables A feature similar to the extension

f

sub class data areas from the data areas generated b y paren t classes is in v

lv

ed in the tec hnique used to implemen t the mec hanism

f

function

v

erriding. The actual represen tation

f

an instance

f

class Class includes more than simply the data elds dened in that class, but is extended to include, as w ell, elds con taining p

in

ters to functions whic h are implemen ted in the giv en class. That is, the instance

f

class Class con taining information ab

ut

the class boolean in the standard library lo

ks

something lik e the follo wing:

SLIDE 7 13.5. VIR TUAL DISP A TCH T ABLES 235 boolean.and boolean.or boolean.not equality.notEqua ls equality.equals

bject.notSameAs
bject.sameAs
bject.asString

parent = equality[boolea n] size = 2 name = "boolean" classPtr The data elds classPtr, name, size, and parent are generated b y the v ariable decla- rations in class

bject

and boolean. The remaining elds do not con tain data v alues, but p

in

ters to functions. The rst three are p

in

ters to functions implemen ted in class

bject,

the next t w

are

deriv ed from functions dened in class equality, while the last three are asso ciated with functions in class boolean. This table

f

functions is traditionally kno wn as a virtual disp atch table (This is b ecause in

ther
b

ject-orien ted languages

v

erridden functions are describ ed as \virtual", and the table is used to dispatc h execution

n

suc h functions.) Sub classes can inherit functions, they can

v

erride existing functions, and they can implemen t new functions. The class True, for example, inherits a n um b er

f

functions from class boolean, and

v

errides four. The virtual dispatc h table generated for this class w

uld

lo

k

as follo ws:

SLIDE 8 236 CHAPTER 13. IMPLEMENTING THE OBJECT-ORIENTED P ARADIGM True.and True.or True.not equality.notEqua ls equality.equals

bject.notSameAs
bject.sameAs

True.asString parent = boolean size = 2 name = "True" classPtr There are sev eral features to note. The rst is that inherited and

v

erridden functions are found in the same lo cation in b

th

the table generated for class boolean and that generated for class True. In exactly the same w a y that the common lo cation

f

data areas p ermits a compiler to generate co de that will w

rk

for an y data v alue deriv ed from a giv en class, the same feature in the class table means that to in v

k

e an inherited function it is simply sucien t to execute the function found at a xed lo cation in the class table. F urthermore, to

v

erride a function it is sucien t to simply replace the p

in

ter in the class table with the p

in

ter to the new function. All functions that are not so replaced are then inherited without c hange. An in v

cation
f

a function inherited in a class structure is con v erted, using this mec h- anism, in to an in v

cation
f

the function found b y indexing the virtual dispatc h table b y a xed amoun t that can b e determined at compile time. F

r

example, to pro duce the prin table represen tation

f

a v alue the dispatc h table is indexed in to lo cation 4 (index v alues start at zero). The function found there will b e the

p

eration appropriate for the v alue b eing manipulated, whether the v alue is a b

lean,

an in teger, a string,

r

an y

ther

t yp e. Note that in eac h

f

these cases a dieren t function will b e in v

k

ed, as eac h class

v

errides the metho d asString in a dieren t manner. Notes and Bibliograph y I discuss a v ariet y

f

dieren t implemen tation tec hniques for

b

ject-orien ted languages in more detail in m y earlier b

k
n
b

ject-orien ted programming [Budd 91b ]. Other expla- nations can b e found in [Co x 86 , Ellis 90 ]. Man y

b

ject-orien ted languages include a feature called \m ultiple inheritance" with whic h a class can inherit features from t w

r

more paren t classes. There are three reasons

SLIDE 9 13.5. VIR TUAL DISP A TCH T ABLES 237 wh y I ha v e not included this feature in Leda. The rst is that the seman tics

f

m ultiple inheritance are not at all clear in all situations (see [Budd 91b ]

r

[Sakkinen 92 ] for a fuller discussion

f

this p

in

t). The second is that in practice programs that use m ultiple inheritance can usually b e replaced b y programs that use single inheritance that are just as concise and clear, if not more so, than their m ultiple coun terparts. Finally , the implemen tation

f

m ultiple inheritance is considerably more dicult than the implemen tation

f

single inheritance. In single inheritance, the initial p

rtion
f

a class alw a ys has the same structure as the structure

f

its paren t from whic h it inherits features. But if a class inherits from t w

r

more classes, its initial p

rtion

can matc h the structure

f
ne
r

the

ther

paren t, but cannot matc h b

th.