Chapter 13 Implemen ting the Ob ject-Orien ted P aradigm In - PDF document

Chapter 13 Implemen ting the Ob ject-Orien ted P aradigm In this c hapter w e will discuss some of the di�culties in v olv ed in implemen ting those features of Leda that are relev an t to the ob ject-orien ted paradigm. 13.1 Memory La y out In Chapter 10 w e in tro duced the concept of a p olymorphic v ariable. That is, in an ob ject- orien ted language it is p ossible to declare a v ariable whic h can hold a n um b er of di�eren t t yp es of v alues o v er the course of execution. The only limiting restriction in this regard is that all suc h v alues m ust b e instances of classes whic h inherit from a single common ancestor class, whic h m ust b e the class used in the declaration of the p olymorphic v ariable. In Chapter 12 w e discussed some of the man y uses for suc h v alues. The presence of p olymorphic v ariables in tro duces a n um b er of in teresting problems for the language implemen tor, problems whic h are not found in the implemen tation of more con v en tional languages. The �rst suc h di�cult y w e will consider is concerned with the allo cation of 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 of space in a �xed lo cation in memory , or in a �xed lo cation in a blo c k of memory called an activation r e c or d that is allo cated once at the b eginning of a function in v o cation, and released when a function terminates. Supp ose, for example, that w e imagine a function whic h uses one lo cal in teger v ariable named x , and also declares one lo cal v ariable named poly whic h is a record con taining three 1 in teger data �elds. An activ ation record for suc h a pro cedure migh t lo ok as follo ws: 1 In practice activ ation records also con tain space for parameter v alues, and for v arious \b o okk eeping" 229

230 CHAPTER 13. IMPLEMENTING THE OBJECT-ORIENTED P ARADIGM poly -- first field poly -- second field poly -- third field x No w imagine that is not a simple record structure, but is instead a p olymorphic poly v ariable declared as b eing an instance of a class whic h de�nes three in teger data �elds. The de�ning c haracteristic of p olymorphic v ariables w as that they can hold that w ere values generated from sub classes. So next imagine that a sub class of the class from whic h poly w as declared de�nes t w o 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 on the righ t of the assignmen t con tains �v e in teger data �elds. The memory allo cated to con tains space only for three in teger data �elds. Simply put, the problem poly is that w e are trying to store more information in to a �xed size b o x than it can hold: poly -- first field first field ( poly -- second field second field poly -- third field third field fourth field fifth field The solution in Leda is to eliminate altogether the idea that a v ariable de�nes a �xed size b o x. 2 Instead, all v ariables are in realit y p oin ters. When a v alue is assigned to a v ariable, only this p oin ter �eld is c hanged. The v alue to whic h it p oin ts can then b e an y size whatso ev er, with no limitations b eing imp osed at compile time. first field second field poly third field - fourth field fifth field Unfortunately , a negativ e consequence of this decision is that it naturally leads to the p oin ter seman tics for assignmen t whic h, as w e noted at the b eginning of Chapter 10, can o ccasionally b e somewhat confusing. v alues, suc h as return address �elds. These details are unimp ortan t for our discussion here. 2 Note that this is not the only solution. The language C++, for example, tak es an en tirely di�eren t approac h, simply slicing o� the extra �elds during assignmen t.

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 ound to a v ariable in a w a y that ensures the v alue will outliv e the con text in whic h it is created. This can o ccur, for example, if a v alue is assigned to a v ariable from a surrounding con text. T o illustrate, consider the follo wing program, whic h uses the functional v ersion of 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 m ust exist ev en after the function has escape 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 or C. Instead, all v alues in Leda are dynamically allo cated on 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 oin ters An imp ortan t prop ert y of p olymorphic v ariables is that the selection of whic h of man y p ossible v ersions of an o v erridden function to in v ok e in an y particular situation dep ends up on the actual, run-time or dynamic t yp e held b y suc h a v ariable, and not on the de�ned, or static t yp e with whic h it w as declared. Th us, it is a requiremen t of all ob ject-orien ted languages that all suc h v alues p ossess at least a rudimen tary form of \self-kno wledge" concerning their o wn t yp e, and b e able to use this kno wledge in the selection of a function to execute. In Leda this self-kno wledge is em b o died in a data �eld that declared in class object , and th us is common to all ob jects (see Figure 13.1). This �eld is declared as an instance of class Class . Class Class main tains information sp eci�c to eac h de�ned class. In particular, this information includes the name of the class as a string, the n um b er of data �elds de�ned in eac h class (that is, the size of eac h instance), and a p oin ter to the paren t class. The metho d tak es as argumen t a v alue, and returns true if the v alue is an isInstance instance of a giv en class (either directly or through inheritance). T o do this, the function mak es use of the relational op erators, whic h ha v e b een rede�ned to indicate the class-sub class relationship. The less-than op erator tak es t w o classes, and returns true if the paren t class of the left argumen t, or an y ancestor of this paren t, is the same as the righ t argumen t. The default meaning of the equalit y op erator indicates whether the t w o argumen ts (that is,

232 CHAPTER 13. IMPLEMENTING THE OBJECT-ORIENTED P ARADIGM class object; var f p oin ter describing ob ject g classPtr : Class; ... end; class Class of ordered[Class]; var name : string; size : integer; parent : Class; function asString()->stri ng; begin return name; end; function less (arg : Class)->boolean; begin f g if self == arg then equal, not less return false; if parent == arg then return true; return parent <> self & parent < arg; end; function isInstance (val : object)->boolea n; begin return val.classPtr <= self; end; end; function typeTest [T : object] (val : object, aClass : Class)->T; begin if aClass.isInstance (va l) then return cfunction Leda object cast(val)->T; return NIL; end; Figure 13.1: The class p oin ter and the class Class