Mo delling Ob jects in PICT

JeanGuy Schneider Markus Lump e

Software Comp osition Group

IAM

January

Abstract

For the development of presentday applications programming languages supp orting

high order abstractions are needed These high order abstractions are called com

p onents Since most of the currently available programming languages and systems

fail to provide sucient supp ort for sp ecifying and implementing comp onents we are

developing a new language suitable for software comp osition It is not clear how such

a language will lo ok like what kind of abstractions it must supp ort and what kind

of formal mo del it will b e based on Ob jectoriented programming languages address

some of the needs of presentday applications and it is therefore obvious to integrate

some of their concepts and abstractions in the language As a rst step towards such

an integration we have to dene an ob ject mo del Since no generally accepted formal

ob ject mo del exists we have chosen the  calculus as a basis for mo delling In order

to nd a suitable ob ject mo del we have built up an ob ject mo delling workbench for

PICT an implementation of an asynchronous  calculus In this work we dene a

rst abstract ob ject mo del describ e several implementations of the ob ject mo del in

PICT and discuss interesting features and p ossible extensions

Keywords  calculus PICT ob ject mo delling software comp osition

CR Categories and Sub ject Descriptors D Programming Techniques

Concurrent Programming D Programming Techniques Ob jectoriented Pro

gramming D Software Engineering RequirementsSpecication D Pro

gramming Languages Language Constructs and Features F Mathematical Logic

and Formal Languages Formal Languages

Authors address Institute for Computer Science and Applied Mathematics

IAM University of Berne Neubr uckstrasse CH Bern Switzerland email

fschneidrlumpegiamunibech WWW httpiamwwwunibechscg

Introduction

Software development and maintenance has always b een an exp ensive task To reduce

its costs sp ecialpurp ose programming languages and metho ds have b een developed and

used For presentday applications however which are getting more complex and increas

ingly op en these metho ds and languages are not suitable any more new ones have to b e

developed that address op en systems requirements

Mo delling Ob jects in PICT

Ob jectoriented programming addresses some of the needs of presentday applications

but only oers limited supp ort for viewing applications as congurations of adaptable and

reusable software comp onents

What we need are higher abstractions than classes and ob jects These higher abstractions

are comp onents b eing congurable entities which can b e comp osed to build an applica

tion ND Unfortunately most ob jectoriented techniques fail to provide suitable ab

stractions for general comp onent sp ecication and comp onent comp osition comp osition

mechanisms NM In order to get a system for comp osition where comp onents can b e

sp ecied and implemented but also comp onents written in other systemslanguages can

b e used we have to dene our own comp osition language In this language we would like

to integrate and combine asp ects concepts and paradigms of existing languages and sys

tems and develop an abstract mo del for software comp osition NGT NM Since a lot

of new applications run in distributed environments our mo del for software comp osition

must also supp ort the denition and use of concurrent comp onents

According to Nie the development of concurrent ob jectbased programming languages

has suered from the lack of any generally accepted formal foundation for dening their

semantics Several formal mo dels have b een presented refer to Men for a summary

but none of them has b een used as a formal basis for mo delling software comp osition

Unfortunately it is not clear what kind of formal mo del is suitable for software com

p osition Therefore we have to dene and implement several mo dels which need to b e

evaluated

The  calculus is a calculus in which the top ology of communication can evolve dy

namically during evaluation Mil It has b een successfully used to mo del ob jects

Jon BSa and simple ob jectoriented programming languages Wal Therefore

it seems to b e a go o d formal foundation for mo delling software comp osition esp ecially

since it p ossible to embed the calculus into the  calculus where metho ds for program

reasoning have b een developed Fortunately there exists an implementation of an asyn

chronous  calculus Pieb which has already b een used for the implementation of a

simple ob ject mo del PT This ob ject mo del lacks several abstractions available in

most ob jectoriented languages but can b e used as a basis for further mo delling Based

on this mo del we try to nd other implementations of ob jects in PICT in order to obtain

an ob ject mo delling workbench Using this workbench it will b e easier to evaluate and

implement ob ject mo dels which can b e used as a basis for a comp osition language As a

rst step towards a mo delling workbench we will only concentrate on mo delling common

abstractions used in ob ject technology which are not necessarily concurrent Full concur

rency will b e introduced in a later stage but we will already discuss problems and p ossible

solutions due to a concurrent ob ject mo del

In this work we rst dene an abstract ob ject mo del based on ob ject mo dels used in other

programming languages section In section we describ e several implementations of

our mo del and cite interesting features of PICT Finally in section we summarize our

work and mention future p ossible work

Mo delling Ob jects in PICT

Ob ject Mo del

As mentioned ab ove it is not clear what kind of ob ject mo dels are suitable for software

comp osition In order to b e able to evaluate several ob ject mo dels we think that the

mo delling workbench should contain features of already existing ob ject mo dels As a

starting p oint we have dened a rst abstract ob ject mo del which will b e used throughout

the rest of this work It has b een strongly inuenced by the ob ject mo dels of C Str

Eiel Mey and Ob ject Pascal BF and supp orts the following features

class variables

class metho ds

instance variables

instance metho ds

selfreference of ob jects

inheritance

genericity

static and dynamic binding

To keep the rst mo del simple metho ds and variables of a class are either exp orted to

clients public or hidden private no selective exp ort like in Eiel will b e mo delled A

1

sub class of a given class will inherit all public features and private instance variables

from its sup erclass but none of the private metho ds A sub class can redene any of its

inherited public features Although it might b e necessary to mo del multiple inheritance

we will not discuss problems due to this mechanism

Since we do not know yet what kind of features are necessary for an ob ject mo del for

software comp osition it is p ossible that we have to add other features to our list They

will b e added and mo delled during evaluation

In Figure the interfaces of two example classes are describ ed in pseudoco de notation

which will b e used throughout the rest of this work to explain our ob ject mo dellings in

PICT The example classes use most of the features introduced ab ove The class IntStack

denes a class for integer stacks with its usual features The keyword public is used to

dene features of a class which are exp orted to clients whereas private denotes features

only visible within the class common is used to dene features shared by all ob jects of

a class class variables and metho ds and override is used to sp ecify an inherited feature

which will b e redened The class IntStack has a class variable Pushed which is used

to count the number of items pushed on all stacks The class IntTower is a sub class of

IntStack where it is only p ossible to push items in a decreasing order A description of

b oth classes can b e found in App endix A or in BL

1 The term feature is used like in Eiel it denotes metho ds and variables of a class

Mo delling Ob jects in PICT

class IntStack f

private

Lo calPushed Integer

Contents List of Integer

public

function empty Bo olean

procedure push Value Integer

procedure p op

function top Integer

function lo calPushed Integer

private

Pushed Integer common

public

function pushed Integer common

g

class IntTower IntStack f

private

function CanPush Value Integer Bo olean

public

procedure push Value Integer override

g

Figure Abstract ob ject mo del

Implementation in PICT

In this section we will describ e several PICT implementations of the abstract ob ject

mo del Readers not familiar with the language PICT can nd an introduction in Pieb

or Var For additional background in the  calculus please refer to Mil Mil

Details ab out the implementation of PICT esp ecially its type system are describ ed in

Tur

Ob ject mo del of Pierce and Turner

In PT Pieb Tur Pierce and Turner introduce a simple ob ject mo del based on

pro cesses an ob ject is a pro cess consisting of

a server pro cess with some internal state b eing able to service requests of clients to

query and manipulate the state and

a set of request channels which can b e used by clients to request services

Mo delling Ob jects in PICT

The following pro cess based reference cell Tur illustrates their ob ject mo del

def ref init

let

new Contents

run Contentsinit

in

set abs vc Contents Contentsv c end

get abs r Contentsv Contentsv rv end

end

A pro cess based reference cell consists of an internal channel Contents which is used to

store the internal state of the ob ject and two request channels set to set a new state

and get to read the current state The initial state of the reference cell is set by the init

parameter In order to protect against other pro cesses reading and writing Contents its

declaration and initialization is wrapp ed in a lo cal blo ck

Each request channel is the interface to another pro cess Theses pro cesses are dened

as anonymous pro cess abstractions using the keyword abs and are the only pro cesses

b eing able to query and manipulate the state of the ob ject In order to simplify their use

they are packed in a record

The let in end construct denes a pro cess template which can b e used by the

2

function ref to create reference cell ob jects

val cell ref

Requests to an ob ject are p erformed by the usual dot notation

run cellset prInt cellget

The reader may have noticed that are no explicit type annotations in the reference cell

example The correct types are inferred by the type inference algorithm included in PICT

As a rst approach we will base our mo delling on the ob ject mo del describ ed in this

section and extend it wherever needed

Mo del

In Figure the complete PICT co de of our rst implementation is describ ed Like in

the simple ob ject mo del of Pierce and Turner PT Pieb an ob ject is mo delled as

a pro cess instance variables are mo delled as lo cal channels and metho ds are dened as

a record of pro cess abstractions For list pro cessing and exception handling predened

libraries are used Piea Although the implementation only works for integers it can

b e easily extended for any kind of ob jects by introducing a generic parameter Pieb

Figure for an example

In order to mo del the class variable Pushed a global channel Pushed is dened and initial

ized to Each stack ob ject gets this channel as a parameter at creation and can use it as

2

The pro cess ref can b e seen as a reference cell factory

Mo delling Ob jects in PICT

def IntStack Pushed Int

let

new LocalPushed

run LocalPushed

new Contents List Int

run Contents nil

def empty res ContentsaList ContentsaList resnullaList

in

record

empty empty

push abs vc ContentsaList LocalPushedv Pushedg

Contentscons v aList

LocalPushedv Pushedg c end

pop abs c

if empty then

raiseexitOnExn Pop on empty stackc

else

ContentsaList LocalPushedv Pushedg

ContentscdraList LocalPushedv

Pushedg c

end end

top abs t

if empty then

raiseexitOnExn Top on empty stack

else

ContentsaList

ContentsaList tcaraList

end end

localPushed abs l LocalPushedv LocalPushedv lv end

end

end

new Pushed class variable

run Pushed

def pushed g Pushedv Pushedv gv class method

Figure Source co de of rst mo del

if it were an instance variable Of course any other pro cess can also mo dify the contents

of this channel and therefore we do not have the kind of data encapsulation needed

The call of pop or top is only valid if the stack is not empty on a call on an empty stack

an exception is raised and the program terminates Both metho ds have to check whether

there is at least one item pushed onto the stack b efore they can pro ceed Since stack

ob jects already have a function empty it is obvious to use this function within pop and

top Because the simple ob ject mo del of Pierce and Turner do es not lo cal metho d calls

the implementation of empty has to move to the declaration part of IntStack a function

empty is dened within the scop e of IntStack Due to the use of dierent name spaces

in PICT it is p ossible to have a lab el and a pro cess with the same name in the scop e of

a record The request channel empty forwards its requests directly to the lo cal pro cess of the same name

Mo delling Ob jects in PICT

def IntStack Pushed Int

let

in

record

end

end

def IntStackClass

let

new Pushed

run Pushed

in

record

pushed abs g Pushedv Pushedv gv end

Create abs IntStack Pushed end

GetClassName abs IntStack end

end

end

Figure Source co de of second mo del

Stack ob jects can b e created by

val s IntStackPushed

metho ds are called by the usual dot notation

run spush prIntslocalPushed

Several abstractions are not supp orted by this rst mo del For example it is not p ossible

to mo del selfreference of ob jects which is needed for the supp ort of dynamic binding and

the lo cal call of exp orted metho ds and there is no p ossibility to express inheritance This

approach do es not encapsulate common class features class variables and metho ds are

dened and implemented in the global scop e The following mo dels will discuss p ossible

solutions of these problems

Mo del

Throughout the rest of this section we will not show the complete PICT co de of our

implementations but only the ma jor dierences to the previous versions

In order to make the channel Pushed only visible to integer stacks it is not correct to

dene it in the declaration part of IntStack Each stack would get its own nonshared

instance variable Pushed which is not the intended b ehaviour if we want to mo del class

variables To solve the problem of class variables and metho ds we have to nd another

solution

On of the main ideas of CLOS Pae KdRB Smalltalk GR and other recent

publications BSb Chi is the denition of classes as metaobjects and the introduction

Mo delling Ob jects in PICT

of metaobject protocols For the purp ose of mo delling ob jects in PICT we currently do not

intend to introduce a full metaob ject proto col The metaob ject dened by IntStackClass

describ ed in Figure is only resp onsible for the declaration and initialization of class

variables denition of class metho ds and creation of instances of the class The pro cess

abstraction IntStack is dened the same way as in the previous mo del

Before ob jects of the class IntStack can b e instantiated the corresp onding metaob ject has

to b e created

val IntStackMetaObj IntStackClass

Stack ob jects are instantiated by

val s IntStackMetaObjCreate

By introducing metaob jects we are now able to mo del class metho ds and class variables

for the corresp onding class Since PICT is statically typed not only instances of a class

but also the corresp onding metaob ject and all its metho ds are well typed not like in

CLOS or Smalltalk where metaob jects are untyped Therefore the IntStackMetaObj

metaob ject generates integer stacks as desired If we would like to have generic stacks

we have to introduce a generic parameter for IntStackClass refer to section The

only other change is the redenition of Create in IntStackMetaObj

Create abs T Stack TPushed end

Now it is p ossible to create stacks with items of a dierent type like

val s StackMetaObjCreate String

for string stacks The class variable Pushed still counts the items pushed on all stacks

whatever their type of items is In section we will show the implementation of a generic

stack class

Mo del

3

If we want to introduce an pseudo instance variable Self which is the selfreference to

an ob ject Self must have a type which corresp onds to the type of the ob ject Since

PICT uses dierent name spaces for types and pro cess abstractions the type for the class

IntStack is also called IntStack Like all instance variables we will mo del Self as a

lo cal channel Therefore Self is of type IntStack channel of IntStack

As a rst attempt one could try to mo del selfreference as a parameter at ob ject creation

like Pushed

val s IntStackMetaObjCreate s

3

This pseudovariable is comparable to this in C Current in Eiel and self in Smalltalk

Mo delling Ob jects in PICT

def IntStack Pushed Int MetaInfo IntStackClass IntStack

let

val MetaObj unfold MetaInfo

new Self IntStack

in

fold IntStack record

setSelf abs sc Selfs c end

end

end

def IntStackClass IntStackClass

let

new Self IntStackClass

in

fold IntStackClass record

Create abs NewObj SelfMeta SelfMeta

let

val obj IntStack Pushed Meta

in

unfold objsetSelf obj NewObjobj

end end

setSelf abs sc Selfs c end

end

end

Figure Source co de of third mo del

This do es not work in PICT b ecause it is not p ossible to use the value dened in a value

abstraction recursively Therefore the selfreference has to b e assigned after the ob ject has

b een created

val s IntStackMetaObjCreate

run ssetSelf s

The metho d setSelf assigns the value of the ob ject to its pseudovariable Self Figure

In all previous mo dels we did not have to explicitly sp ecify the type of IntStack nor

IntStackClass it is inferred by the type inference system of PICT If we want to use

Self within instance metho ds its exact type has to b e known at the p osition where it is

used If we do not give an explicit type annotation for Self the type inference algorithm

cannot infer the correct type an explicit type annotation is required Since IntStack has

Mo delling Ob jects in PICT

a metho d setSelf with a parameter of type IntStack the type of IntStack is recursive

type IntStack

RecT Record

push IntSig

pop Sig

top Int

empty Bool

localPushed Int

setSelf TSig

end

and the pseudovariable Self is of type IntStack Figure Since we also need to mo del

selfreference of the metaob ject the metaob ject type is dened accordingly

type IntStackClass

RecT Record

pushed Int

Create IntStack

GetClassName String

setSelf TSig

end

Due to the fact that b oth IntStack and IntStackClass are recursive types the program

mer has to take care of correct folding and unfolding of entities of b oth types Piea

unfold transforms a value with a recursive type in one with a nonrecursive type fold is

used for the inverse transformation The ma jor drawback of recursive types is that no

subtype relation can b e established b etween them two recursive types A and B are either

4

equal or noncomparable Since this is not suitable for mo delling inheritance where we

need subtype relations recursive types must b e omitted This will b e a topic of the next

section

Another disadvantage of this mo del is that the metho d setSelf is exp orted which in fact

should not happ en It is p ossible to abuse setSelf like in

val s IntStackMetaObjCreate

val s IntStackMetaObjCreate

run ssetSelfs

which is probably not the way setSelf should b e used

Mo del

The previous mo del Figure has two ma jor disadvantages exp ort of setSelf and use

of recursive types With the mo del introduced in this section we will b e able to get rid of

most of these disadvantages

The metho d setSelf has two preconditions rst it must b e applied as the rst metho d

to the ob ject and second it has to b e used with the ob ject itself as the one and only

4 According to Pierce this will likely b e changed in a future version of PICT

Mo delling Ob jects in PICT

def IntStack Pushed Int MetaObj IntStackClass IntStackImpl

let

new Self IntStack

in

record

setSelf abs sc Selfs c end

end

end

def IntStackClass IntStackClassImpl

let

new Self IntStackClass

in

record

Create abs NewObj IntStack SelfMeta SelfMeta

let

val obj IntStack Pushed Meta

in

objsetSelf obj NewObjobj

end end

end

end

Figure Source co de of fourth mo del

parameter Other usages are forbidden The mo del describ ed in section do es not

guarantee the correct b ehaviour when setSelf is abused In order to prevent abuse

one could think of changing the implementation of IntStack by using choice and event

channels Pieb in a way that setSelf is only accepted as the rst metho d call This

would guarantee the rst precondition the second still remains op en What we need is a

construct where either the use of more than one setSelf causes a compile time error or

setSelf is not used any more In the next section we will show how this is p ossible

As a rst approach for preventing the abuse of metho ds like setSelf and increasing the

p ossibilities of data encapsulation we introduce the notion of interface and implementation

type In the interface type all features meant to b e used by clients of an ob ject are

sp ecied The implementation type extends the interface by implementation details only

used by the ob ject itself and its corresp onding metaob ject Private metho ds of a class are

not part of the implementation type

The interface and implementation type of IntStack and IntStackClass are dened as follows

Mo delling Ob jects in PICT

type IntStack Interface Type

Record

push IntSig

localPushed Int

end

type IntStackImpl IntStack Implementation Type

with

setSelf IntStackSig

end

type IntStackClass MetaObject IntStack Interface Type

with

pushed Int

end

type IntStackClassImpl IntStackClass Implementation Type

with

setSelf IntStackClassSig

end

The with op erator extends a given Record type with new elds If such a eld already

exists it is overwritten by the new one As a step towards a mo dular programming

environment a generic metaob ject type has b een introduced where the common features

of all metaob jects are combined

type MetaObject T

Record

Create T

GetClassName String

end

The Create metho d of the metaob ject Figure creates an ob ject of type IntStackImpl

and can therefore use the metho d setSelf The result channel NewObj on the other hand

is of type IntStack which is a sup ertype of IntStackImpl Since it is p ossible to send

along a channel a value of a subtype of the actual channel type it is safe to send an

ob ject of type IntStackImpl along a channel of type IntStack Although Create creates

an ob ject of type IntStackImpl the static type of the created ob ject is IntStack and

only metho ds dened for this type can b e used The implementation part of the ob ject

has simply b een cut o This is the rst time we use type restriction for improving data

encapsulation

The main reason why a recursive type had to b e introduced in the previous mo del was the

parameter of the metho d setSelf which had to b e equal to the type of the ob ject itself

By changing the type of the parameter to IntStack the type of IntStackImpl is not

recursive any more and the value represented by the channel Self is of type IntStack

With this solution the usage of Self is restricted only to features of the interface type

Another ma jor problem has still not b een solved we have no chance to check whether

the value passed to an ob ject using setSelf is identical to the ob ject itself In order to guarantee the second precondition refer to Page we must lo ok for another solution

Mo delling Ob jects in PICT

def IntStackClass IntStackClass

let

val MetaSelf emptyRef IntStackClass

def Create IntStackImpl

let

val Self emptyRef IntStackImpl

val NewInstance

let

val LocalPushed ref

val Contents ref nil

in

record

pop abs c if Selfgetempty

then

MetaObj MetaSelf Reference Cell of Meta Object

end

end

in

SelfsetNewInstance

Selfget

end

in

end

Figure Source co de of fth mo del

Mo del

The mo dels describ ed in the previous sections still have several problems which we will

solve in this section We will introduce a much more convenient way for mo delling self

references which also leads to a much b etter data encapsulation

As an improvement the pro cess denition IntStack is not in the le scop e any more but

has moved to the declaration part of the metaob ject Now it is not p ossible any more to

create stacks without using the Create metho d of the metaob ject

The rst simple ob ject which is mo delled in Pieb is a reference cell refer also to

section A reference cell is an up datable data structure Tur By using the set

metho d a new value can b e assigned to the reference cell the get function returns the

value actually stored Although a reference cell uses a lo cal channel to store the value

the exact implementation is not of primary concern to us Reference cells can either b e

created by using

val cell ref typeinitVal

where a initial value is set or

val cell emptyRef type

where no initial value is assigned

Mo delling Ob jects in PICT

As shown in Figure the Create metho d of the metaob ject has changed In the declara

tion part an empty reference cell Self and an ob ject NewInstance of type IntStackImpl

are created The value of NewInstance is then assigned as the rst contents of the ref

erence cell As the result of Create the contents of the reference cell the newly created

ob ject is returned Since the name Self and its type is known it can b e used within the

declaration of NewInstance Selfget is nothing other than an alias to NewInstance

and can b e used as the selfreference instead The selfreference cannot b e changed any

more b ecause it is not p ossible to access the reference cell Self from outside the ob ject

The same enco ding is also used to obtain a selfreference of the metaob ject not shown in

Figure This solution has two ma jor advantages an elegant mo delling of selfreferences

and an easy way to make the distinction b etween the internal representation of an ob ject

and its exp orted interface

Although the Create metho d dened in the declaration part of IntStackClass creates

an ob ject of type IntStackImpl the exp orted Create metho d returns an ob ject of type

IntStack Again type restriction is used to hide the implementation part of an ob ject

The mo delling of instance variables has also changed reference cells are used instead of

lo cal channels This has the advantage of making them easier to use but it means that

we can no longer synchronize concurrent accesses Various approaches are p ossible for

avoiding interferences and deadlo ck but a detailed investigation will b e a topic of future

work For some preliminary results in mo delling concurrency control refer to Var

Mo del

One of the main features of ob ject oriented programming is inheritance Usually one

distinguishes b etween interface inheritance and code inheritance Interface inheritance is

not a problem in PICT since it is p ossible to extend a given record type with new elds We

have already used this construct in previous mo dels IntStackImpl inherits the interface

of IntStack Co de inheritance is more dicult What we need is an abstraction where a

subclass of a given class can reuse the co de implemented in its sup erclass In the previous

mo del all pro cess abstractions are dened within the scop e of IntStack No other pro cess

has had the p ossibility to access the implementation The data encapsulation we use is

to o restricted it needs to b e op ened

In order to understand one p ossibility to exp ort the implementation of a pro cess abstrac

tion we have to investigate the translation of the pro cess denition abstraction def into

core PICT A pro cess name dened as

def name par proc

is translated into

new name

run namepar proc

Since pro cess abstractions are translated into channels and channel names are values it

is p ossible to pass a pro cess abstraction to another pro cess By introducing a metho d

getMethods each ob ject can send its private pro cess denitions to other ob jects This

is not a very convenient solution since the exact type of getMethods has to b e sp ecied

Mo delling Ob jects in PICT

type IntStackClass MetaObject IntStack Interface Type

with

pushed Int

Pushed Ref Int

end

type IntStackImpl IntStack Implementation Type

with

MetaObj Ref IntStackClass

Contents Ref List Int

LocalPushed Ref Int

end

def IntStackpop Self IntStackImpl Method Definition in File Scope

if Selfempty then

raise exitOnExn Pop on empty Stack

else

let

val Stk SelfContentsget

val Pushed SelfMetaObjgetPushed

in

SelfContentsset cdr Stk

SelfLocalPushedset SelfLocalPushedget

PushedsetPushedget

end

end

Figure Source co de of sixth mo del

which usually is not trivial and results in redundant type annotations

Due to the fact that pro cess denitions have to b e op ened anyway an easier solution is

chosen Each class declares its instance variables as reference cells in its implementation

type Figure All exp orted metho ds are dened globally with a parameter of the

corresp onding implementation type as an additional rst parameter This is the typical

implementation of C metho ds We use name mangling to unambiguously sp ecify the

5

metho d name The external ob ject interface is not aected by this mo dication Within

a metho d it is necessary to access instance variables or call other instance metho ds by

using the selfreference This is the reason why instance variables have to b e dened in

the implementation type Ob jects can use any of the globally dened metho ds if their

implementation type is a subtype of the rst parameter of the feature This is imp ortant

for mo delling inheritance

An ob jects metaob ject information is stored in a reference cell Therefore it is p ossible to

change the metaob ject of an ob ject which is necessary when ob jects should change their

type at runtime This is often used in prototype based languages Lie Note that it is

only p ossible to change an ob jects metaob ject when the type of the new metaob ject is a

subtype of the ob jects metaob ject type

5

We have chosen ClassNamemethodName to name metho ds

Mo delling Ob jects in PICT

This mo del has an additional prop erty it is the rst mo del supp orting dynamic binding

Dynamic binding is only available for exp orted metho ds but this is not a restriction

b ecause there is no need to bind private metho ds dynamically With this mo del we can

use b oth static and dynamic binding In order to use dynamic binding a metho d has

to b e called through an ob ject Smalltalk terminology sending a message to an ob ject

To force a metho d to b e b ound statically we have to call this metho d directly without

an ob ject The following co de fragment shows the static and the dynamic binding of the

metho d push of the class IntStack

val s IntStackMetaObjCreate

6

IntStackpushs static binding

spush dynamic binding

This example needs some explanations In order to obtain static or dynamic binding

dierent call mechanisms have to b e used For static binding the metho d is called directly

and for dynamic binding the metho d is selected through the exp orted interface of the

ob ject

In order to understand how dynamic binding works we take a closer lo ok at the imple

mentation of C where a metho d table is used to select virtual metho ds This table

contains p ointers to all virtual metho ds which are dened inherited redened or new de

ned for the class Each ob ject has an unnamed hidden instance variable which b elongs

to the virtual metho d table of the class Bor The user has no access to this instance

variable The value of this instance variable is set in the constructors of the class

All ob ject mo dels we have dened so far do not use an explicit metho d table In fact

these mo dels do not supp ort dynamic binding But we have a comparable construct which

can serve as metho d table the interface record

In the interface record the public interface of an ob ject is enco ded Only public metho ds

can b e b ound dynamically Like in C private metho ds are always b ound statically

The interface record initialization hides the name mangling of the metho ds and provides

the user with the original call interface for the metho ds

record

empty abs IntStackemptySelfget end

push abs v IntStackpushSelfgetv end

end

The anonymous pro cess abstractions used to initialize the record values play roughly sp eak

ing the role of p ointers to the metho ds Therefore we have a comparable implementation

of a virtual metho d table in PICT Moreover this implementation has an advantage over

the C solution The current ob ject Self is b ound to the rst parameter within the

initialization of the record elds There is no need to provide the current ob ject as rst

6

This only works if s is of type IntStackImpl

Mo delling Ob jects in PICT

parameter every time a metho d is called like in the C implementation Therefore

the call interface of the metho ds remain the same according to their denition

procedure push Value Integer

is translated into

push absv IntStackpushSelfgetv end

which can b e used like

aStackObjpush

Mo del

In all the previous mo dels we tried to obtain a sucient data encapsulation With the

mo del presented in this section we nally start to mo del inheritance

In Figure we have introduced a class IntTower which is subclass of IntStack As we will

see in this section the corresp onding type IntTower is also a subtype of IntStack

Before the implementation of IntTower can b e mo delled the corresp onding types have to

b e dened

type IntTower IntStack IntTower IntStack

type IntStackClass MetaObject IntStack

with

pushed Int

Pushed Ref Int

end

type IntTowerClass MetaObject IntTower

with IntTowerClass IntStackClass

pushed Int

Pushed Ref Int

end

type IntStackImpl IntStack

with

LocalPushed Ref Int

Contents Ref List Int

MetaObj IntStackClass

end

type IntTowerImpl IntStackImpl IntTowerImpl IntStackImpl

with

MetaObj IntTowerClass

end

Since the class IntTower has exactly the same interface as the class IntStack the interface

type IntTower is equal to the type IntStack and also a subtype of IntStack Both

classes have the same class variables and class metho ds and therefore the corresp onding

Mo delling Ob jects in PICT

def IntTowerClass IntTowerClass

let

def Create IntTowerImpl

let

val Self emptyRef IntTowerImpl

val NewInstance

let

val LocalPushed ref

val Contents ref nil

in

record

empty abs IntStackempty Selfget end

push abs v IntTowerpush Selfgetv end

MetaObj MetaSelfget

end

end

in

SelfsetNewInstance

Selfget

end

in

end

Figure Source co de of seventh mo del

metaob jects have an equal interface type to o As already mentioned on Page metho ds

dened for IntStack can b e used by other ob jects if their implementation type is a subtype

of IntStackImpl Hence it is necessary to dene the implementation types in a way that

IntTowerImpl is a subtype of IntStackImpl This can b e achieved by slightly mo difying

the implementation type introduced in Figure the ob jects metaob ject information is

not stored in a reference cell any more but as a constant This is necessary b ecause if

type A is a subtype of B then Ref A is not a subtype of Ref B any more

The implementation of IntTower is shown in Figure It is very similar to the one of

IntStack in the previous section Figure instance metho ds are dened in the le

scop e instance variables are implemented using reference cells One may notice that the

7

private metho d CanPush is not part of the implementation type of IntTower but is

still has to b e dened in the le scop e and not in the declaration part of IntTower

A small problem arises when a sub class redenes a metho d but still needs to call the

inherited metho d IntTower redenes push but still needs the version implemented for

IntStack Since PICT do es not supp ort op erator overloading CW name mangling

is used to unambiguously name metho ds with the same name but implemented for

dierent classes refer also to Page

Whenever inheritance is introduced the question is whether it is p ossible to redene

7

For the complete implementation of CanPush refer to Figure

Mo delling Ob jects in PICT

val StackClass TStack T

let

val pushed ref

in

abs T

let

val localPushed ref

val Contents ref nil

in

record

empty abs nullContentsget end

localPushed abs localPushedget end

end

end

end

end

Figure Source co de of generic pro cedural stack class

inherited features in a covariant or contravariant way Mey and what the consequences

are Well if a metho d is redened in a covariant way eg the type of a parameter is

replaced by a subtype the sub class is not a subtype of the sup erclass any more Hence

none of the metho ds or functions dened for the sup erclass can b e used they have to

b e all rewritten By redening a metho d in a contravariant way eg replacing the type

of a parameter by a sup ertype the sub class is still a subtype of the sup erclass but the

inherited version of a redened metho d cannot b e used any more

In principle we can now mo del all the features introduced in our ob ject mo del in section

but is there a b etter solution We answer this question in the next section

Mo del

In this section we will introduce a dierent approach for mo delling ob jects It is based

on a Scheme Dyb implementation describ ed in FWH see also App endix B The

main dierence to the previous mo dels is that the stack class is not dened as a process

abstraction using def but as a value expression Figure This guarantees that only

one metaob ject instance p er class exists Instance metho ds are again dened in the scop e

of the value expression and are therefore only accessible by ob jects of the corresp onding

class The implementation describ ed in Figure do es not supp ort class metho ds nor self

reference but again we can mo del selfreference using a reference cell according to Mo del

which is done for the TowerClass implementation in Figure Class metho ds will b e

reintroduced in the next section

The careful reader may have noticed that we have mentioned a few times p ossible ex

tensions to our implementation in order to dene generic classes even in the presence of

metaob jects In order to show an example how generic classes can b e dened in PICT we

have slightly changed our implementation and dened a generic stack class StackClass

The type of the value StackClass is equal to TStack T where the type Stack

Mo delling Ob jects in PICT

val TowerClass

abs Tgreater T T Bool

let

val Self emptyRef TowerImpl T

val Super StackClass T

def CanPush v private method

if Selfgetempty then

true

else

if greater Selfgettop v

then true

else false

end

end

val NewInstance

Super with

push abs v

if CanPushv then

Superpushv

else

raiseexitOnExn Tower Invalid Push

end end

end

in

Selfset NewInstance

Selfget

end

end

Figure Source co de of generic pro cedural tower class

is dened as

type Stack T

Record

push TSig

pop Sig

top T

empty Bool

localPushed Int

end

Due to the fact that we have only introduced explicit type annotations where it was

needed only very few changes have to b e made to the IntStack implementation in order

to obtain a generic stack

To mo del inheritance we also take a dierent approach we use delegation semantics A

sub class do es not inherit the features of its sup erclass but has an instance of its sup erclass

Figure A similar approach is used in Self US and Sina Aks Ber

Mo delling Ob jects in PICT

Probably this mo delling needs a few words of explanation The with op erator cannot

only b e used to extend a Record type with new elds refer to Page but also to

extend and redene a record value If a eld exists more than once only the last eld is

valid all others get overwritten This mechanism is used in TowerClass to inherit and

redene features from StackClass Due to the fact that a sub class do es not inherit from

its sup erclass but has an instance instead only the exp orted features of the sup erclass

can b e accessed internal representation and implementation is not visible This has the

consequence that dynamic binding is not p ossible If the sub class redenes a metho d which

is called by another metho d dened in an ancestor class and not redened in the sub class

the original and not the redened metho d will b e called Although this do es not seem to

b e desirable it could b e a rst approach for an ob ject mo del for software comp osition

b ecause the b ehaviour of an ob ject do es not implicitly dep end on its environment it can

only b e changed explicitly In order to achieve dynamic binding the sup erclass ob ject

must b e explicitly told which metho d implementation has to b e called inherited version

or redened version or a dierent approach to implement metho ds has to b e found

But this mo del has also its advantages Since a sub class cannot access the private instance

variables of its ancestor its implementation do es not dep end on the ancestors implemen

tation If concurrent ob jects are dened we think that we can omit inheritance anomalies

MY by using our kind of mo del but this still is a sub ject of current research Another

p oint is that it is not necessary any more to use name mangling for naming metho ds a

metho d foo is simply called by Selfgetfoo or Superfoo

Like the stack implementation the tower implementation describ ed in Figure is generic

The metho d CanPush has to compare the top element with each item to b e pushed onto

the tower In the previous mo del the op erator is used for that which is only dened

for integers and its subtypes but not for any other type Because PICT do es not

8

allow op erator overloading each tower ob ject needs a comparison op erator valid for the

type of elements stored In order to implement a generic tower each tower ob ject has

to b e furnished with the valid comparison op erator for example with a parameter at

instantiation like in Figure

Mo del

In this section we extend the last mo del in order to obtain dynamic binding again What

is the problem When we use inheritance we instantiate an ob ject of the sup erclass

When we redene a metho d of the sup erclass the redened metho d will only b e used in

the subtype It is not p ossible to force the sup erclass ob ject to use the redened metho d

The reason why dynamic binding is not supp orted by this approach is that Self within the instance of the sup erclass refers to the sup erclass ob ject but not to the sub class ob ject

Super

Self Tower Stack Self

To achieve the eect of dynamic binding Self of the sup erclass ob ject has to refer to the

8

In C the op erator would simply b e overloaded

Mo delling Ob jects in PICT sub class ob ject

Self

Super

Self Tower Stack

What we need is an instance of a sup erclass ob ject where Self refers to the sub class ob ject

To do so we introduce socalled intermediate objects where all metho ds and instance

variables of a class are dened but where Self is unbound all metho ds have an additional

rst parameter Self The metaob ject of each class denes a pro cess CreateIntermediate

comparable with a generator in Co o CP where the intermediate ob ject of the class

is dened

def CreateIntermediate defined in IntStackClass

let

val LocalPushed ref private instance variables

val Contents refnil

in

record

empty abs Self IntStackImpl nullContentsget end

push abs Self IntStackImpl v end

localPushed abs Self IntStackImpl LocalPushedget end

end

end

In the Create metho d of the metaob ject an intermediate ob ject is created each exp orted

metho d is b ound to a metho d dened in the intermediate ob ject and the correct binding

of Self is established Like in the previous mo del an empty reference cell is used to mo del

selfreference

def Create IntStack defined in IntStackClass

let

val IntStackIntermediate CreateIntermediate

val Self emptyRefIntStackImpl

val NewInstance

record

empty abs IntStackIntermediateemptySelfget end

push abs v IntStackIntermediatepushSelfget v end

end

in

SelfsetNewInstance

Selfget

end

Besides the implementation of all public class metho ds and the metho d Create which

creates new ob jects like in the previous mo del the metaob ject exp orts the metho d

CreateIntermediate This metho d returns a fresh copy of an intermediate ob ject of the

class

The mo delling of inheritance is now straightforward In order to reuse the metho ds dened in an ancestor class the metaob ject of a class gets a fresh copy of the intermediate ob ject

Mo delling Ob jects in PICT

of its direct sup erclass This intermediate ob ject is then used to dene the intermediate

ob ject of the class itself It is p ossible to i override metho ds ii dene new metho ds

and iii call inherited metho ds

def CreateIntermediate defined in IntTowerClass

let

val SuperIntermediate IntStackClassCreateIntermediate

def CanPush Self IntTowerImpl v

check whether v is smaller than top

in

SuperIntermediate with

push abs Self IntTowerImpl v

if CanPushSelfv then

SuperIntermediatepushSelfv

else

raiseexitOnExnTower Invalid Push

end end

end

end

The Create metho d of the tower metaob ject is dened in the same way as in the stack

class For the complete co de of the stack and tower classes refer to App endix C

A further change in comparison to Mo del is that private instance variables have b een

removed from the implementation type The way we use delegation do es only allow the

access to public features We think that the implementation type can b e used to mo del

protected features but this is a topic of future research

The reader should note that this mo del has the disadvantage that the metho d

CreateIntermediate is exp orted by the metaob ject This violates data encapsulation

but it is necessary to obtain co de reuse There is no need that a client of an ob ject uses

this metho d

Conclusion and future work

In the last section we have introduced several implementations of ob ject mo dels The idea

b ehind the work was not to nd only one implementation for a sp ecic mo del but to

obtain an ob ject mo delling workbench for PICT Using this workbench it will b e easier to

dene a suitable ob ject mo del for software comp osition We did not only try to keep the

implementations simple but also tried to write generic co de in order to reuse co de as much

as p ossible All the mo dels we have presented so far are sequential mo dels Although the

goal is to nd a concurrent ob ject mo del we have concentrated on sequential asp ects of

ob ject mo dels as a rst step Besides nding other implementations the denition and

mapping of a concurrent ob ject mo del will b e the goal of our future work as a next step

towards an ob ject mo del for a comp osition language

PICT is a suitable language for mo delling ob jects although there are a few language

features which make mo delling a bit dicult First of all recursive types do not only

require explicit folding and unfolding by the programmer but no subtype relation can b e

established b etween them Reference cells are very handy to mo del variables but they do

Mo delling Ob jects in PICT

require a more sophisticated concurrency control and they interfere with subtype relations

if the type A is a subtype of B then Ref A is neither a subtype of Ref B nor vice versa

to o

There are some features which could b e introduced into PICT in order to obtain a more

ecient co de reuse For example it should b e p ossible to annotate the type parameters

9

of a type op erator with an upp er b ound like

type T

type TO X T

The type op erator TO can now only b e used when its type parameter is of type T Esp ecially

in the context of dening record types for ob jects this would b e very handy A useful

extension would b e a type op erator to merge two given Record types to get one record

type and another op erator to merge two record values to form one record

In PICT it is p ossible to have anonymous pro cess denitions using abs but it is not

p ossible to have anonymous type denitions Sometimes it would b e easier to declare

a value with no type annotation and use the type of the previously declared value to

dene another type or value This could b e achieved by introducing a typeof op erator

returning the static type of an expression This op erator could then b e used in a context

where a type is required

Last but not least in none of our ob ject mo dels it was p ossible to compare ob jects Since

ob jects are mo delled as records a generic comparison op erator for records is required

which is not available in the current version of PICT A solution to this problem is the

assignment of an unique integer value to each ob ject which can b e used to compare

ob jects Of course this can only b e used to check whether to variables have a reference to

the same ob ject but it is not p ossible to compare to nonidentical ob jects having the same

abstract representation

Probably a very challenging work would b e to nd a minimal set of extensions to PICT in

order to get a real ob jectoriented programming language like CLOS is an ob jectoriented

extension to Common Lisp KdRB

Acknowledgements

We thank all the members of the Software Comp osition Group for their supp ort of this

work esp ecially Oscar Nierstrasz and Patrick Varone and Benjamin Pierce and Manuel

Barrio for reviewing and many helpful comments

References

Aks Memeth Aksit On the Desing of the ObjectOriented Language Sina PhD

thesis University of Twente NL

9 Similar to constraint genericity in Eiel

Mo delling Ob jects in PICT

Ber Lo dewijk Bergmans Composing Concurrent Objects PhD thesis University

of Twente NL June

BF A Burda and G Farber Das grosse Buch zu DELPHI Data Becker

BL Michel BeaudouinLafon Objectoriented Languages Basic principles and pro

gramming techniques Chapman Hall

Bor Op en Architecture Handb o ok Borland International Inc Scotts Valley CA

BSa Manuel Barrio Solorzano Estudio de Aspectos Dinamicos en Sistemas Orien

tados al Objecto PhD thesis Universidad de Valladolid September

BSb Sren Brandt and ReneW Schmidt The Design of a MetaLevel Architecture

for the BETA Language In Proceedings of META Workshop on Advances

in Metaobject Protocols and Reection at ECOOP August

Chi Shigru Chiba A Metaob ject Proto col for C In Proceedings of OOPSLA

volume of ACM SIGPLAN Notices pages Octob er

Co o William R Co ok A Denotational Semantics of Inheritance PhD thesis De

partment of Computer Science Brown University Providence RI May

CP William Co ok and Jens Palsberg A denotaional semantics of inheritance and

its correctness Information and Computation

CW Luca Cardelli and Peter Wegner On Understanding Types Data Abstraction

and Polymorphism ACM Computing Surveys December

Dyb R Kent Dybvig The SCHEME Programming Language Prentice Hall

FWH Daniel P Friedman Mitchell Wand and Christopher T Hayens Essentials of

Programming Languages McGrawHill

GR Adele Goldb erg and David Robson Smal ltalk The Language Addison

Wesley September

Jon Cli B Jones A PiCalculus Semantics for an Ob jectBased Design Notation

In E Best editor Proceedings of CONCUR LNCS pages

Springer

KdRB Gregor Kiczales Jim des Rivieres and Daniel G Bobrow The Art of the

Metaobject Protocol MIT Press

Lie Henry Lieb erman Using Prototypical Ob jects to Implement Shared Behaviour

in Ob ject Oriented Systems In Proceedings OOPSLA volume of ACM

SIGPLAN Notices pages November

Men Tom Mens A survey on formal mo dels for OO Technical Rep ort vubtinftr

Department of Computer Science Vrije Universiteit Brussel Belgium

Mo delling Ob jects in PICT

Mey Bertrand Meyer Objectoriented Software Construction Prentice Hall

Mey Bertrand Meyer Eiel the Language Prentice Hall

Mil Robin Milner A calculus of mobile pro cesses part II I Technical Rep ort ECS

LFCS Computer Science Department University of Edinburgh UK

Mil Robin Milner The p olyadic Picalculus a tutorial Technical Rep ort ECS

LFCS Computer Science Department University of Edinburgh UK

Octob er

MY Satoshi Matsuoka and Akinori Yonezawa Analysis of inheritance anomaly

in ob jectoriented concurrent programming languages In Gul Agha Peter

Wegner and Akinori Yonezawa editors Research Directions in Concurrent

ObjectOriented Programming pages MIT Press

ND Oscar Nierstrasz and Laurent Dami Comp onentOriented Software Technol

ogy In Oscar Nierstrasz and Dennis Tsichritzis editors ObjectOriented Soft

ware Composition pages Prentice Hall

NGT Oscar Nierstrasz Simon Gibbs and Dennis Tsichritzis Comp onentOriented

Software Development Communications of the ACM Septem

b er

Nie Oscar Nierstrasz Towards an Ob ject Calculus In Mario Tokoro Oscar Nier

strasz and Peter Wegner editors Proceedings of ECOOP Workshop on

Objectbased Concurrent Computing LNCS pages Springer

NM Oscar Nierstrasz and Theo Dirk Meijler Requirements for a Comp osition Lan

guage In Paolo Ciancarini Oscar Nierstrasz and Akinori Yonezawa editors

ObjectBased Models and Languages for Concurrent Systems LNCS pages

Springer

Pae Andreas Paepcke editor ObjectOriented Programming The CLOS Perspec

tive MIT Press

Piea Benjamin C Pierce Pict User Manual Computer Lab oratory University of

Cambridge UK May

Pieb Benjamin C Pierce Programming in the PiCalculus An exp eriment in con

current language design Technical rep ort Computer Lab oratory University

of Cambridge UK May Tutorial Notes for Pict Version a

PT Benjamin C Pierce and David N Turner Concurrent Ob jects in a Pro cess

Calculus In Takayasu Ito and Akinori Yonezawa editors Theory and Practice

of Parallel Programming TPPP LNCS pages Springer April

Str Bjarne Stroustrup The Design and Evolution of C AddisonWesley

Mo delling Ob jects in PICT

Tur David N Turner The Polymorphic PiCalculus Theory and Implementation

PhD thesis Department of Computer Science University of Edinburgh UK

US David Ungar and Randall B Smith SELF The Power of Simplicity In Pro

ceedings OOPSLA volume of ACM SIGPLAN Notices pages

December

Var Patrick Varone Implementation of Generic Synchronization Policies in

PICT Technical Rep ort IAM University of Bern Institute of Com

puter Science and Applied Mathematics February

Wal David J Walker Ob jects in the PiCalculus Information and Computation

A Complete IntStack and IntTower classes

Stack class f

elds

stack arrayN of integer

top integer

metho ds

pro cedure Push value integer

pro cedure Pop

function Top integer

g

pro cedure StackPush value integer f

top top

stacktop value

g

pro cedure StackPop f

top top

g

function StackTop integer f

return stacktop

g

Tower class Stack f

metho ds

pro cedure Push value integer

function CanPush value integer b o olean g

Mo delling Ob jects in PICT

function TowerCanPush value integer b o olean f

if top

then return true

else return value < Top

g

pro cedure TowerPush value integer f

if CanPush value

then StackPush value

else errorWrite push imp ossible

g

B Pro cedural stack class implementation in Scheme

This Scheme implementation can b e found in FWH on page

define makestack

let pushed

lambda

let stk localpushed

lambda message

case message

empty lambda null stk

push lambda x

set pushed pushed

set localpushed localpushed

set stk cons x stk

pop lambda

if null stk

error Stack Underflow

begin

set pushed pushed

set localpushed localpushed

set stk cdr x stk

top lambda

if null stk

error Stack Underflow

car stk

localpushed lambda localpushed

pushed lambda pushed

else error Stack Invalid message message

Mo delling Ob jects in PICT

C Pro cedural stack classes with dynamic binding

class IntStack

type IntStack

Record

empty Bool

push IntSig

pop Sig

top Int

localPushed Int

end

type IntStackImpl IntStack

type IntStackIntermediate

Record

empty IntStackImplBool

push IntStackImplIntSig

pop IntStackImplSig

top IntStackImplInt

localPushed IntStackImplInt

end

type IntStackClass

Record

pushed Int

GetClassName String

Create IntStack

CreateIntermediate IntStackIntermediate

end

val IntStackClass

let

val MetaSelf emptyRef IntStackClass Self reference

val Pushed ref class variable

def pushed Pushedderef class method

def CreateIntermediate IntStackIntermediate

let

val LocalPushed ref

val Contents refnil

def empty Self IntStackImpl nullContentsderef

def push Self IntStackImpl newval

LocalPushedsetLocalPushedderef

PushedsetPushedderef

Contentssetcons newval Contentsderef

def pop Self IntStackImpl

if Selfempty then

raiseexitOnExnPop on empty stack

else

PushedsetPushedderef

LocalPushedsetLocalPushedderef

Mo delling Ob jects in PICT

ContentssetcdrContentsderef

end

def top Self IntStackImpl

if Selfempty then

raiseexitOnExnTop on empty stack

else

carContentsderef

end

def localPushed Self IntStackImpl LocalPushedderef

in

record

empty empty

push push

pop pop

top top

localPushed localPushed

end

end

def Create IntStackImpl

let

val Self emptyRef IntStackImpl Self reference

val IntermediateSelf CreateIntermediate

val NewInstance

record

empty abs IntermediateSelfemptySelfderef end

push absv IntermediateSelfpushSelfderefv end

pop abs IntermediateSelfpopSelfderef end

top abs IntermediateSelftopSelfderef end

localPushed abs

IntermediateSelflocalPushedSelfderef end

end

in

SelfsetNewInstance binding of Self

Selfderef

end

val NewMetaInstance

record

pushed pushed

GetClassName abs IntStackClass end

Create Create

CreateIntermediate CreateIntermediate

end

in

MetaSelfsetNewMetaInstance binding of Self

MetaSelfderef

end

class IntTower

type IntTower IntStack

Mo delling Ob jects in PICT

type IntTowerImpl IntTower

type IntTowerIntermediate IntStackIntermediate

with

push IntTowerImplIntSig

end

type IntTowerClass IntStackClass

with

Create IntTower

CreateIntermediate IntTowerIntermediate

end

val IntTowerClass

let

val MetaSelf emptyRef IntTowerClass Self reference

def CreateIntermediate

let

val SuperIntermediate IntStackClassCreateIntermediate

def CanPush Self IntTowerImpl v

if Selfempty then

true

else

if Selftop v

then true

else false

end

end

def push Self IntTowerImpl newval

if CanPushSelfnewval then

SuperIntermediatepushSelfnewval

else

raiseexitOnExnTower Invalid Push

end

in

SuperIntermediate

with

push push

end

end

def Create IntTowerImpl

let

val Self emptyRef IntTowerImpl Self reference

val IntermediateSelf CreateIntermediate

val NewInstance

record

empty abs IntermediateSelfemptySelfderef end

push absv IntermediateSelfpushSelfderefv end

pop abs IntermediateSelfpopSelfderef end

top abs IntermediateSelftopSelfderef end

localPushed abs

Mo delling Ob jects in PICT

IntermediateSelflocalPushedSelfderef end

end

in

SelfsetNewInstance

Selfderef

end

val NewMetaInstance IntStackClass

with

GetClassName abs IntTowerClass end

Create Create

CreateIntermediate CreateIntermediate

end

in

MetaSelfsetNewMetaInstance

MetaSelfderef end