Classifying Prototyp ebased

Programming Languages

C Dony J Malenfant and D Bardou

1

LIRMM Universite de Montp ellier II

rue Ada Montp ellier Cedex France

Email donylirmmfr

2

URVALORIA Universite de Bretagne sud

CGU de Vannes rue de la Loi Vannes France

Email JacquesMalenfantunivubsfr

Abstract The prototyp ebased programming mo del has always b een

dicult to characterize precisely Prototyp ebased languages are all based

on a similar set of basic principles yet they all dier in their precise in

terpretation of these principles Moreover if the prototyp ebased mo del

advo cates concrete ob jects as the only mean to mo del concepts cur

rent languages promote metho dologies reintro ducing abstract construc

tions to manage eciently groups of similar ob jects In the past we

have prop osed two classications of delegationbased languages in or

der to clarify these issues In the present pap er we come back to these

two classications in the light of our recent work The rst classication

lo oks at the primitives of the virtual machine underlying each language

it classies languages according to the semantics of these primitives

The second considers the grouporiented constructions provided in each

language it classies languages according to the level of abstractness

of these constructions The two classications complements each others

and also other existing classications They allow p eople to assess more

precisely the relative merits of the dierent languages

Intro duction

A prototyp e is a typical memb er used to represent a family or a category of

ob jects Prototyp ebased languages prop ose a vision of ob jectoriented pro

gramming based on the notion of prototyp e Since the middle of the eightees

numerous prototyp ebased languages have b een designed and implemented self

kevo agora garnet moostrap

cecil omega newtonscript Other languages such as object

lisp or yafool not qualied as prototyp ebased nevertheless oer closely

related mechanisms or use prototyp es at the implementation level Finally sys

tems mixing prototyp es and classes have also b een prop osed

A very general and informal characterization of prototyp ebased languages is

rather simple they prop ose a world in which there is one kind of ob jects equip ed

with attributes and metho ds three primitives to create ob jects creation ex

1

We use that term to denote a structural characteristic of an ob ject or frame

nihilo cloning and extension dierential copy and one control structure mes

sage sending together with a delegation mechanism Beyond this generalization

all these languages present slight yet profound and interesting dierences

They are dierent b ecause they have b een develop ed for dierent application

domains They are dierent b ecause they have b een inspired on the one hand by

the earlier frame languages used in knowledge representation and on the other

hand by actors languages used in distributed AI They are also dierent b ecause

they have b een develop ed with dierent goals

The rst goal was to provide simpler descriptions of ob jects Peoples nat

ural way to grasp new concepts is generally to b egin by creating concrete

examples rather than abstract descriptions classbased languages force p eo

ple to work in the opp osite direction by creating abstractions classes prior

concrete ob jects instances

The second goal was to oer a simpler programming mo del with fewer con

cepts and primitives Applications in the elds of userinterfaces and

virtual reality have tried to escap e the traditional abstract data typ e

mo del to move towards a less constrained one For these applications classes

have b een considered as a source of complexity b ecause they are playing to o

many roles The alternative solution is often based on the concept of pro

totyp es more amenable to a form of programmingbyexample and providing

an alternative to class instantiation and class inheritance

The last goal was to oer new capabilities to represent knowledge Class

based languages constrain ob jects by disallowing for example distinctive

b ehavior for individual ob jects among their instances and by forbidding in

heritance b etween ob jects to share values of instance variables

Thus an exact and unique characterization of prototyp ebased programming

raises a numb er of issues Current prototyp ebased languages dier in

the semantics of ob ject representation ob ject creation ob ject encapsulation

ob ject activation and ob ject inheritance

There exists various interpretations of what is a prototyp e a concrete ob

ject or an average representative of a concept which can lead to dierent

languages

The semantics of the basic mechanisms cloning dierential copy delegation

is not unique and allows for dierent interpretations

Dierential copy creates interdep endent ob jects and authorizes various in

terpretations concerning the precise nature of the concept of ob ject they

implement

Finally some of the capabilities oered by classes for example the ability to

express sharing at a conceptual level have revealed to b e so imp ortant for

program organization that they have b een reintro duced in dierent ways

So understanding each language b oth in terms of their expressive p ower

and their applicability to sp ecic kinds of problems is not always easy The

Frame Frame

name whale name MobyDick

category mammal isa whale

environment sea color white

enemy man enemy CptHaccab

weight

color blue

Fig Dierential description

Fig Example of Frame

Treaty of Orlando prop oses a rst comparison of classbased and prototyp e

based languages we go further by addressing more extensively the issues p ending

the alternative semantics asso ciated to pure prototyp ebased languages and the

level of abstration propsed by the dierent mecahnisms reintro ducing class func

tionalities into prototyp edbased languages In the past we have prop osed two

complementary classications to this end The goal of the present pap er is to

come back to these two classications in order to present and explain their main

classication criteria but also to complement them in the light of our recent

work

The rest of the p qp er is organized as follos Section recalls the genesis

of prototyp ebased programming and thus prop oses a rst classication of lan

guages Section prop oses a rst classication of prototyp ebased languages

according to the vision their conceptor had on them Section presents the com

parison criteria related to primitive op erations and mechanisms that constitute

a prototyp ebased language virtual machine Section presents the comparison

criteria related to how programs written in prototyp ebased languages are orga

nized Section prop oses the two classications of languages according to the

previously dened criteria

Genesis of the Prototyp eBased Programming Mo del

To understand the genesis of ideas is a rst imp ortant step in a classication pro

cess This section recalls how framebased and actor languages have inuenced

prototyp ebased ones

Prototyp es and knowledge representation

The concepts of prototyp e and dierential description can b e found in the frame

theory and in some systems inspired from this theory such as the framebased

languages krl or frl Frames have b een designed as an alternative way

to represent knowledge such as typicality default values or exceptions which

are dicult to describ e in other formalisms Framebased languages use the

prototyp es theory and they have inuenced some prototyp ebased languages

Structure A frame is a set of attributes Each attribute represents one

characteristic of the frame and is made of a couple attribute name set of

facets The most common facet and the only one considered in our examples

is the attributes value The gure shows a denition of a frame representing

a whale

Dierential description Dierential description makes it p ossible to cre

ate a new frame by only expressing the dierences from an existing one The

dierential description creates a relation b etween the new frame and the former

its prototyp e or parent This relation is implemented by a link generally called

isa The gure shows the denition of a frame representing MobyDick

which lo oks like the ab ove whale but is white and has a sp ecic enemy

Frame hierarchies and inheritance The isa relation is an order rela

tion that denes frame hierarchies A frame can inherit from its parent a

set of attributes Framebased systems prop ose inheritance hierarchies made of

representatives of concepts which are conceptually very similar to those built

later with prototyp ebased systems One can generally nd at the top of those

hierarchies average representatives such as whale and at the b ottom concrete

representatives such as MobyDick What is tremendously imp ortant here is

that what is shared are not descriptions as with class inheritance but rather

concrete representations and so bindings of slots to values

Actor languages

To represent entities with classless ob jects has also b een prop osed in descrip

tions of act although the pap ers related to this language dont mention

neither the prototyp e concept nor its use in the earlier framebased languages

act provides ob jects and mechanisms conceptually close to those describ ed

ab ove and part of the fundamental characteristics of to days prototyp ebased

language

From our p oint of view the main dierence b etween the framebased lan

guage krl quoted ab ove and act is that act is a programming and not a

representation language Actors thus have attributes acquointances and a set

of b ehavior We will use the term metho d to denote the representation of a

b ehavior and the term prop erty to denote either an attribute or a metho d

Metho ds are invoked by sending messages to actors The gure shows an ac

tor named point with two attributes and one metho d Actors b eing classless

ob jects are created by cloning and extending existing ones with three primitives

create extend and cextend

Cloning Although a copy primitive did exist in earlier languages such as

smalltalk act has intro duced cloning shallow copying as a primitive way

2

The object being used as a basis for comparison which we cal l the prototype pro

vides a perspective from which to view the object being described It is quite

possible and we believe natural for an object to be represented in a know ledge sys

tem only through a set of such comparisons

3

This link may b e accessible to the programmer via a related attribute also called

isa

4

This simplied vision is sucient here in fact metho ds are group ed in a script and

invoked via pattern matching

object extend point

x y

Point Point2

norm lambda 3 x x 5 y

y 10 30

create point print point

print printing

y norm x

norm norm computation

lambda newX newY

moving move move

setq x newX y newY

extend turtle

turtle point

y 0 heading heading

moving in a direction forward

forward lambda

Fig Cloning and extension in act

to create new ob jects The simple biological metaphor of cloning makes it very

app ealing compared to the traditional way to create ob jects in classbased mo d

els namely by instantiation The basic idea is that given an existing and co

herent ob ject it is easier to get a new ob ject similar to the rst one by simply

copying it than to instantiate correctly a new one with coherent initial values for

its instqnce variables Another primitive called create combines cloning and

addition of new prop erties For example in Figure point is a clone of point

with new attributes values and to which a new metho d has b een added

Extension Dierential description is conceptually similar to that of frames

and is p erformed by a primitive called extend which creates a new actor that

we will call an extension of its mo del The mo del is called the proxy and is the

equivalent of the parent or prototyp e in the frames terminology The gure

shows the denition of a Logo turtle actor as an extension of point A turtle

is like a p oint but as a heading and a forward b ehavior to move in the direction

dened by its heading What we call extension should not b e confused with the

p ossibility to add new attributes to ob jects

Inheritance and delegation The relation b etween an actor and its proxy

is really similar to the isa relation b etween frames This relation is implemented

by a link named proxy that we will also call parent in the rest of the pap er

An extension can inherit prop erties of its proxy The inheritance is achieved

whenever an actor do es not know how to handle a message in which case it

explicit delegation or the system implicit delegation can ask its proxy to

answer for it The transfer of control to the proxy is called delegation Pap ers on

act do not precise the context in which a metho d is executed after a delegation

the binding of self this mechanism is however a rst form of what will b ecome

delegation in prototyp ebased languages

5

Whenever an actor receives a message he cannot answer immediately on the basis

of his own local know ledge he delegates the message to another actor cal led his

proxy

Dierent visions of Prototyp eBased Programming

The ab ove systems contain the essence of what has b een later called prototyp e

based programming The rst studies that led to the design of classless ob ject

oriented programming languages have b een published in the middle of the eigh

tees They brought to the fore various issues generally related to classbased

programming and prop osed various solutions based on the use of prototyp es

This section recalls these early prop osals and thus supp orts classication based

on the vision their conceptors had and the problems they wanted to solve

Prototypical instances and cloning A simpler programming

mo del

The classbased mo del is complex classes play dierent roles that

makes program design dicult In reaction to this complexity in a quest for a

simpler programming mo del Borning has prop osed an informal description of

a classless language in which new ob jects are pro duced by copy and mo dication

of prototyp es Once the copy is done no relation is maintained b etween the

copied prototyp e and its clone The resulting programming mo del is simple but

quite p o or in term of sharing and in term of program organization As far as

we know the mo del has not b een pursued by its author but has inspired some

complete cloning and prototyp ebased languages such as kevo omega

and obliq

Prototypical instances and dierential description A new way

to conceive ob jects

At the same time and partially for the same reasons but also mainly to prop ose

a new way to conceive and dene ob jects Lieb erman has prop osed to applied

some ideas extracted from act to ob jectoriented programming He

has describ ed an informal programming mo del based on prototypical instances

cloning and dierential description Many dierent languages have b een inspired

by his work and share basically the same characteristics self objectlisp

newtonscript moostrap etc self has attracted the largest development

eort and it has b een widely distributed

As a prototypical example of such languages we can give a avor of object

lisp which has a wellknown lisp syntax The gure shows an objectlisp

version of the prototypical p ointturtle example Ob jects have attributes and

metho ds they can b e cloned and extended Extension ob jects have a parent and

inherit their prop erties Activation is based on message sending function ask

There is no encapsulation attributes can b e accessed via message sending ask

turtle x or through their name within metho ds Delegation can o ccur either

to retrieve the value of an attribute or to activate a metho d if the receiver do es

6

Let us quote instance descriptors metho d libraries supp ort for encapsulation shar

ing and reuse supp ort for the architecture of programs etc

setq point kindof Creating an object ex nihilo

ask point have x Creating an attribute for point

ask point have y

defobfun norm point A method norm for point

sqrt x x y y variables are the receivers ones

defobfun move point newx newy A method with parameters

ask self have x x newx to add two points

ask self have y y newy Modifying values of attributes

defobfun plus apoint p A method to add two points

let newx x ask p x

newy y ask p y

newp kindof apoint Creating an extension of the object

ask newp have x newx passed as parameter

ask newp have y newy

newp

setq point kindof point point is an extension of point

ask point have y with a new attribute y

setq turtle kindof point An extension of point

ask turtle have cap with a new attribute cap

defobfun forward turtle dist and a method forward

ask self move dist cos cap

dist sin cap

objectlisp is an extension of Lisp towards objects al lowing both message passing

and traditional function cal l Message passing is implemented by the function ask

its rst argument is the receiver and the second a function cal l where the name of a

function is used as message selector a method corresponding to that name must exist

the arguments of the function cal l are the arguments of the message The fol lowing

primitives are used in the example

creating objects ex nihilo function kindof without arguments

creating extensions functions kindof with one argument which is the extended

object

method denition function defobfun

attribute denition method have

Fig A prototyp ebased language example objectlisp

not hold the required prop erty Delegation can here b e describ ed informally in

the following way an ob ject that cannot answer a question can delegate it to its

parent if the parent can answer it the answer will b e p erformed in the context

of the values of the original ob ject Thus compared to act the fundamental

new p oints are explicit description of p olymorphism and dynamic binding In our

example the metho d norm is p olymorph b ecause it can b e applied to a p oint or

to a turtle Dynamic binding ensures that a metho d executed after a delegation

is applied in the context of the initial receiver in our example sending the

message norm to turtle returns

Classless ob jects knowledge representation

Another motivation to study classless languages was a quest for greater exibility

to represent knowledge and express sharing in ob jectoriented programs

As shown by the frame exp erience prototyp es oer new capabilities to rep

resent knowledge dicult to grasp in classbased languages such as

dierent ob jects of the same family having dierent structures and b ehaviors

exceptional ob jects

ob jects with viewp oints and sharing at the ob ject level

incomplete ob jects to b e classied

Such capabilities although widely used are more sp ecically the mark of

a family of hybrid languages combining declarative knowledge representation

and programming Representatives of such languages are garnet the

ob ject layer of which named KR b eing prototyp ebased which is dedicated to

graphical user interfaces or yafool which is a knowledge representation

language based on frames that can have metho ds in the sense of traditional

ob jectoriented languages

Class and ob ject hierarchies Disconnecting subtyping and

reuse

A last family is made of languages that integrates b oth prototyp es and classes If

several prop ositions have b een made in this direction and have inuenced actual

languages this family has yet to pro duce a concrete representative

Indeed one of the rst prop osal emb edding ob ject hierarchies has

suggested to mix in a single world classes and instances called examplars hav

ing some kind of autonomy The main purp ose of that prop osition was related

to ob jectoriented program organization it was meant to exp eriment a sepa

ration b etween subtyping hierarchies b etween classes and co de inheritance hi

erarchies or implementation hierarchies b etween instances In this prop osal

ob ject metho ds are stored in instances and typ e interfaces in classes classes can

have dierent instances with dierent implementations of the same metho d For

example the instances emptylist and nonemptylist of the class list have

a dierent version of the append metho d New ob jects are created by cloning

instances for example new lists are created by cloning either emptylist or

nonemptylist Besides any instance can inherit from any other some pri

vate metho ds necessary for the implementation of the metho ds that comp ose its

interface The delegation hierarchy b etween instances is not necessarily isomor

phic to the inheritance hierarchy b etween classes

Although such prop osals have not b een pursued they have inuenced actual

languages and represent in our opinion a source of new ideas for the applications

of the prototyp es formalism

7

By the way the non isomorphic interface and class hierarchies of java each class

implementing one interface is a new form of that idea

Classication criteria related to primitive mechanisms

The classication of the previous section is based on various visions of what is

classless programming and on various application domains for prototyp ebased

programming We now fo cus on a classication based on the primitive op erations

of prototyp ebased languages Beyond a set of similar basic principles ob ject

centered representation dynamic addition and deletion of slots cloning and

delegation prototyp ebased languages dier in the precise interpretation of the

primitives that constitute their virtual machine and in the way programs are

organized To build some classications reecting those dierences requires to

present the comparison criteria

Ob ject Representation

Ob jects in prototyp ebased languages are dened by a set of prop erties A prop

erty is basically the binding within the ob ject of name to a value Prop erties

are conceptually of two kinds attributes or metho ds Two main solutions have

b een considered for the representation of ob jects to separate the concepts

of attributes and metho ds or to amalgamate them using the concept of slot

The rst alternative mimics ob jects of a traditional classbased approach the

value of each attribute can b e accessed within metho ds by referencing its name

and can b e changed through assignment In the second alternative no distinc

tion is made b etween variables and metho ds instead an ob ject gets a collection

of slots where a variable can b e viewed as a metho d that simply returns a value

Distinction b etween variables and metho ds are ob jects represented

with attributes and metho ds or with slots

Indeed b oth alternatives have advantages and disadvantages The advan

tages of slots are advo cated by self they are more exible they allow

users to access in the same way attributes and metho ds they p ermit to override

an attribute with a metho d and conversely a metho d with an attribute How

ever they force to implement an explicit encapsulation mechanism With the

variablesmetho ds approach encapsulation of variables can b e simply enforced

by establishing standard smalltalklike visibility rules objectlisp cf

Fig do es not provide such rules variables can b e accessed via message

sending

Criteria related to ob ject creation and evolution

Two alternatives are p ossible to create new ob jects in current languages An

ob ject can b e created ex nihilo or it can b e created from an existing one by

cloning or extending it Whether or not a primitive to create new ob jects ex

nihilo is provided makes up our second criteria

8

A prop erty can also have a typ e a domain facets

Creation ex nihilo is it p ossible to create new ob jects ex nihilo

If a primitive to create new ob jects ex nihilo is provided two new alternatives

show up We can create empty ob jects or ob jects with an initial structure If

we restrict ourselves to the creation of new empty ob jects alone this raises the

question of what to do with them Some means must b e provided to mo dify

their structure in order to build the concrete ob jects in applications Indeed

this intro duce two other design alternatives can the structure of ob jects b e

extended andor shrunk dynamically by adding or deleting prop erties

Dynamic mo dication of ob ject structure can ob jects structure b e

mo died

Consider the creation of new ob jects from existing ones The rst solution is

cloning Most languages except garnet and amulet provide a primitive for

cloning ob jects Cloning cf Section in itself oers two alternatives shallow

cloning or deep cloning However deep cloning is usually ruled out as an unin

teresting alternative b ecause it is time consuming and provide little interesting

prop erties on its own The second solution is extension and is discussed in the

next section

Extensions and other solutions for lifetime sharing b etween

ob jects

A new alternative app ears with the question of extension ob jects cf Sections

and are extensions necessary and what do they add to cloning Some lan

guages do not provide primitives to create extensions of other ob jects For ex

ample kevo only allows for cloning and adding new prop erties to clones The

ob ject point in gure is a clone to which a new prop erty has b een added it

would have b een p ossible to dene turtle by cloning point and by adding the

new ob ject the prop erties heading and forward

The dierence b etween an extension and an augmented clone lies in the way

ob jects share prop erties From the sharing and reuse p oint of view shallow

cloning essentially means that immediately after cloning the corresp onding slots

of an ob ject and its clone will p oint to the same ob jects For example consider

point and its clone point in the same gure they share the metho d print

and their p osition by the virtue of p ointing to the same value ob jects through

their resp ective slots print x and y However even if they get the same structure

and the same values they have indep endent slot bindings if point is mo died for

example the two ob jects cease sharing the values of the up dated slots If a new

prop erty is added to point point will not have it Hence shallow cloning en

force creationtime sharing characterized by an indep endent evolution of the

clone and the copied ob ject which prevents ob jects to b e unexp ectedly mo died

through their clone The indep endent evolution applies to slot individually here

point and point continue to share the metho d move even after points y

slot has b een mo died

With extensions we face lifetime sharing the extension inherits the prop

erties of its parent and as long as the ob jects exist the sharing will continue

In our example turtle will continue to share the y slot of point even if this

slots value is mo died Moreover if a new prop erty is added to point turtle

will inherit it

Cloning and extension mechanisms are thus dierent and have distinct ap

plications

Do es the language provide b oth cloning and extension mechanisms

When an extension mechanism is provided some languages allow new ob jects

to b e extensions of more than one ob ject There is no conceptual dierence

this p ossibility simply raises usual multipleinheritance problems when accessing

inherited prop erties Some languages also allow an ob ject to change its parent

at runtime this is called dynamic inheritance in self

Multiple parents is it p ossible to have multiple parents

Dynamic inheritance is it p ossible for an ob ject to change its parent

When no extension mechanism is provided achieving lifetime sharing b e

tween ob jects requires other groupwide mechanisms For example kevo makes

p ossible via a mechanism that we will call propagation to add for example a

new metho d to all ob jects of the same clone family This requires of course

that such families b e handled automatically by the system

If the language provides no extension mechanism is there a

propagationlike mechanism allowing to achieve some kind of life

time sharing

Message sending

As in other ob jectoriented languages the basic control structure of prototyp e

based languages is message sending The alternatives with message sending lie

in the way metho ds are searched In the simplest case metho ds are simply

searched in the ob ject that has received the message However most prototyp e

based languages provide a sharing mechanism named delegation Delegation can

b e implicit or explicit

Implicit delegation is used go es hand in hand with a corresp onding exten

sion mechanism Delegation here is a kind of inheritance mechanism allowing

to retrieve access or apply prop erties of an ob ject which are in fact owned by

its parents Implicit delegation was rst intro duced by Lieb erman see Sec

tion as a message forwarding mechanism who has accurately describ ed it

in see Section With implicit delegation when an ob ject do es not own

the requested metho d or attribute the interpreter automatically delegates the

question to the ob ject p ointed by its parent link point2 point2 x 5 x 5 y 14 y 10 add ... add ... move ... move ...

turtle turtle x 10 x 10 y 14 heading 90 heading 90 forward ... forward ...

rotate ... rotate ...

Fig after the mo dication of y with Fig after the mo dication of y with

prop erty sharing value sharing

Another form of delegation is qualied as explicit where any ob ject can ex

plicitely delegate via a sp ecic instruction a request to another ob ject Explicit

delegation is quoted in act and is also used in obliq achieved through an

alias mechanism

If the language provides a delegation mechanism is delegation im

plicit or explicit

Extensions delegation and sharing

The next comparison criterion is related to the interpretation that is given to

the notion of extension Such an interpretation governs the exact semantics of

the delegation mechanism More precisely the interpretation given to the exten

sion mechanisms governs what is inherited by an extension and what is shared

b etween an extension and its parent The delegation mechanism is resp onsible

for correctly achieving inheritance and sharing To intro duce those dierent in

terpretations let us recall that any ob ject created in a program represents an

entity b eing represented in the program which is part of the real world we call

the set of such entities the domain of the program

Delegation as a sharing mechanism b etween representation of dierent

entities In the rst interpretation that we will call value sharing interpretation

the notion of extension is used to express attribute and metho d values sharing

b etween two ob jects representing dierent entities of the domain For example

consider again in the gure the ob ject turtle created as an extension of

point The ob ject turtle represents a Logo turtle of the domain and the ob ject

point represents a p oint of the domain The reason why the turtle ob ject is

made a child of the point ob ject is clearly the reuse of the denition of points

prop erties We do not want points prop erties to b e the very prop erties of JoePerson growOld age := age + 1 address 8 Octave street age 30 name John phone 11-11-11-11

parent link

JoeFilmEnthusiast JoeSportsman favActor ... stamina ... favFilm ... weight ...

favDirector ...

Fig A representation of a p erson with three ob jects

turtle but rather point to provide default values for the turtles variables

which are not redened An ob ject has at least as many prop erties as its parent

each of these prop erties is identied by the same name within the context of any

of the two ob jects and has the same default value If the entities are distinct

the ob jects cannot share prop erties but only prop erty values

What ab out delegation With this interpretation an ob ject should not b e

mo died by sending an assignment message to one of its descendants For ex

ample an assignment message for the slot y sent to turtle should not result in

points y value mo dication as shown in Figure but rather in the denition

of the y variable in turtle as shown in Figure In other words assignment

messages or write access to attributes in metho ds b o dies should not b e dele

gated but should eventually entail a lo cal redenition of the attribute Parent or

delegation links can in this case b e intended as islikea links Delegation then

grants read access to variables but no more write access to the parent prop er

ties The frontiers b etween ob jects are then clearer in our example point and

turtle can b e considered as two dierent ob jects b ecause they can evolve almost

on their own The only way to mo dify the value of the points y variable is to

explicitly send a message to point Although this will also mo dify the y slots

value for turtle this may b e acceptable in a sense since this value is intended

to b e a default one

In terms of sharing such an interpretation of variable assignment amounts to

restrict b etween an extension and its parent prop erty sharing to value sharing

the ob ject turtle do es not share with point the prop erty named y but the

value of that prop erty as long as it is not redened on turtle

Delegation as a sharing mechanism b etween representation of view

p oint on the same entity In a second interpretation that we will call

9

Lieb erman has also suggested ob jects as default b ehavior and value rep ositories for

their children in

property sharing interpretation an extension ob ject and its parent can b e

seen as dierent parts of the same domain entity In such a case prop erties of

the parent can b e seen as full prop erties of the extensions To split a representa

tion in several ob jects in a delegation hierarchy is a natural way of representing

viewp oints

For example consider ob jects collectively representing a p erson say Jo e

in a delegationbased system as shown in Figure The ob ject

JoePerson holds the basic information ab out the p erson its address age name

and phone and a metho d growOld while the ob ject JoeSportsman an exten

sion of JoePerson holds information related to Jo e as a sp ortsman Creating

JoeSportsman as an extension ob ject instead of simply adding the slots salary

and company to JoePerson also leaves the do or op en for other extensions eg

Jo e as a lm enthousiast Any mo dications to JoePerson are automatically

seen by its extensions Also changes to the p erson Jo e can b e made through

its extension ob jects For example if the employee changes its p ersonal address

the change will naturally b e made at the p erson level and will b e eective for all

extensions of this p erson As in a description hierarchy the most general view

p oints are those denoted by the ob jects near the top of the hierarchy whereas

the most sp ecic viewp oints are those denoted by the ob jects which are leaves

of the hierarchy In our example p erson is a more general viewp oint on Joe than

either sp ortsman or lm enthusiast

What ab out delegation With this interpretation it is coherent that an ob ject

may b e mo died by sending an assignment message to one of its descendants

For example asking JoeSportsman to change its age can and even has to result

in a mo dication of the attribute age of JoePerson

In terms of sharing this interpretation is an application of prop erty sharing

b etween ob jects The address or age prop erties not only their values are shared

by the ob jects JoePerson JoeSportsman and JoeFilmEnthusiast Prop erty

sharing is a characteristic of the extension mechanism and is achieved through

the delegation mechanism

Interpretation of the extension mechanism When the language pro

p oses an extension mechanism is it with a prop erty sharing or

value sharing interpretation

A short analysis Fully analysing these choices go es b eyond the scop e if this

pap er A rst partial analysis can b e found in and more recent ones in

Let us just insist that the prop ertysharing interpretation raises some en

capsulation issues when used in a p ointturtle like example indeed delegation

establishes a so strong link b etween the ob jects point and turtle that they

cannot any more b e considered as representing distinct entities Conversely it

enables split representations A split representation is a set of ob jects linked

by delegation representing a single entity of the domain such as the p erson

Jo e There is as far as we know in to days prototyp ebased languages no way o1 Clyde color grey legs 4 ears 2

o2 Fred parent

color white

Fig Dierential creation of the prototyp e o representing Fred from the prototypical

instance of elephants also representing Clyde

to handle split representations as rstclass ob jects entities for which we have

coined the name split objects Handling split ob jects in a language would mean

to create them refer to them clone them and otherwise deal with them as with

other ob jects This is an op en issue on which we are currently working

Besides the valuesharing interpretation partially eliminates encapsulation

issues by making parents indep endent of their extensions but it also restrict

the expressive p ower of the language by forbidding split representation with

viewp oints

Classication criteria based on program organization

Despite the basic principles of prototyp ebased programming which advo cates

concrete ob jects as the only mean to mo del concepts current languages have

intro duced mechanisms to deal with groups of similar ob jects The three most

common ones are prototypical instances traits ob jects and maps

Early in the foundation of prototyp ebased programming Lieb erman has pro

p osed the mechanism of prototypical instances to share prop erties among ob jects

related to a similar concept The essential idea is to use the rst concrete ex

ample of a concept as the representation of the concept itself The wellknown

elephant example illustrates this Fig Here the ob ject o represents the

elephant Clyde which is the rst elephant we have encountered Clyde is there

fore chosen as the representation of the concept of elephant It is grey has four

legs and two ears When the white elephant Fred app ears delegation allows us

to dierentially create Fred as an ob ject o having o as parent and simply

redening the slot color to b e white

Traits and maps have b een invented in the prototyp ebased language self

A traits ob ject is a rep ository for metho ds and semiglobal variables

applying to the whole group of its delegating ob jects The traitbased program

ming mo del prop oses to segregate the slots of a prototypical ob ject in two

parts the representation part and the proto col part Typically the proto col part

consists of slots holding metho d values while the representation part will consist o1 x 10 y 20 display method for displaying points

add method for adding points

Fig A p oint example

traits points display method for displaying points add method for adding points

o1 parent o2parent o3 parent x 10 x 0 x 3

y 20 y 0 y 5

Fig A p oint example using a traits ob ject

of slots holding either ob ject identiers or constant values but this need not

to always b e the case In our rst example Fig the representation part of

a p oint ob ject would include the slots x and y while the proto col part would

include the slots display and add A traits ob ject is an ob ject holding the pro

to col part the idea b eing that this ob ject can b e shared among several copies

of the representation part themselves represented as ob jects see Fig

Traits encourage the creation of delegation hierarchies that lo ok like an in

heritance one in its higher levels made of traits At the leaves we nd concrete

ob jects somewhat like the instances in classbased programming Traitbased

programming leaves more exibility in the creation of ob jects and traits are not

classes they are less exible and less abstract An op eration traitof returning

the rst parent traits of an ob ject can b e provided testing whether two ob

jects supp ort the same proto col then b oils down to test if the two ob jects traits

are the same or have a common parent In this sense traitbased programming

emphasizes the notion of similar b ehavior among ob jects

A map factors structural information out of ob jects in a clone family ie a

group of structurally identical ob jects obtained by cloning one another Maps

illustrated in Figure are similar to standard prototyp es except that the slot

values are replaced by indexes giving the relative p osition of the slot values in

the ob ject now represented merely as a vector of slot values In fact self go es

b eyond that by putting in the map the values of immutable slots an existing

concept in this language When an ob ject receives a message the selector is used

to lo ok up the map to nd a slot index a value or a metho d If a value is found it point map o1 x 1 y 2 10 o2 display 3 20 add 4 0 0 method for displaying points

method for adding points

Fig The p oint example using maps

is returned if a metho d is found it is applied in the context of the receiver if an

index n is found the content of receivers nth slot is retrieved and either returned

if it is a value or applied if it is a metho d In self maps are created automatically

b ehind the scene and if an ob ject is cloned the two clones will share the same

map They give self the same space eciency in the representation of ob jects

as the one of classbased languages Because maps are not ob ject in self they

have no direct inuence on its programming metho dology

Generalization

Prototypical instances traits and maps are sp ecic mechanisms used in existing

languages to structure programs Compared to the original ob jectives of the

prototyp ebased mo del we have argued that they are going against the very

notion of prototyp ebased programming as it has b een originally dened But

from them emerge a much richer notion of delegationbased programming In fact

delegationbased languages exhibit much more diversity than it rst app eared

b ecause these new mechanisms imp ose slightly dierent programming mo dels

which can hardly b e put under the same prototyp ebased hat

This approach allows us to complement existing classications such as the

one presented in the previous section but also the ones of Wegner and

the Treaty of Orlando Wegner identies the class of ob jectcentered pro

gramming languages as classless ob jectbased languages within which he singles

out delegationbased languages ie classless objects with delegation In our

p oint of view Wegners classication underestimates the diversity of classless

ob jectbased languages indeed b ecause it is an attempt to characterize the whole

design space of ob jectoriented language Moreover at the time of his writing

delegationbased languages were still underinvestigated It is in this sense that

we complete his classication b eing more precise in one of his original class

10

A little confusion app ears in where ob jectbased languages are understo o d as

always classless

We prop ose to classify delegationbased programming languages according

to the numb er of dierent kinds of ob jects and the numb er of dierent kinds of

links they manipulate For example the parentof link of delegation is one link

manipulated in all delegationbased programming languages Similarly a trait

based programming language manipulates two kinds of ob jects concrete ones

and traits We argue that the numb er of kinds of links and ob jects manipulated

in a language b ears imp ortant insights into the nature of its programming mo del

We explore four classes of delegationbased languages languages with one kind

of ob ject and one kind of link ones with two kinds of ob jects and one kind of

link ones with two kinds of ob jects and two kinds of links and nally ones with

one kind of ob ject and two kinds of links This classication is founded on four

illustrating languages the formal semantics of which have b een develop ed and

thoroughly examined

Prototyp ebased languages have always b een criticized for their lack of man

ifest organization in programs Our new classication brings to the fore the

existence of delegationbased languages with a more and more structured pro

gramming mo del forming a continuum b etween pure prototyp ebased languages

and classbased ones Not only this shows that the organization of a program

can b e made more explicit without sacricing an ob jectcentered programming

mo del it also suggests a step by step p ossibly automatic transformation of

prototyp ebased programs into classbased ones a programming metho dology

advo cated b efore

Languages based on one kind of ob ject and one kind of link

Delegationbased languages where the space of ob jects is completely homoge

neous and where delegation is used for sharing corresp ond to the usual notion

of prototyp ebased languages All ob jects are equally rstclass entities they can

b e created dynamically they can b e sent a message they are all mutable they

can b e passed as parameters and returned as results All of them can b e used as

parent and cloned We categorize these languages as having one kind of ob ject

and one kind of link namely the parentof link

Two kinds of ob jects one kind of link

Typically a language with one kind of ob ject and one kind of link will evolve

towards one with two kinds of ob jects when some ob jects b ecome exceptional

compared to others Ob jects can b ecome exceptional b ecause of a particular

programming metho dology that must b e supp orted at the language level in

order to have all its strength They also b ecome exceptional when their rst

classness is severely restricted such as b eing immutable or abstract in the

sense that they cannot answer messages They may not b e cloned or used as

parents We illustrate this category of languages with a traitbased programming

language

The traitbased programming mo del is a go o d example for this class of lan

guages having two kinds of ob jects prototyp es and traits and one kind of link

delegation In prototyp ebased programming while assumed to b e a concrete

ob ject the traits ob ject will fail if sent messages since presumably the corre

sp onding metho ds will try to send the receiver self messages accessing the

representation part which will fail In fact for traitbased programming to work

prop erly most traits ob jects must never receive messages And we prop ose that

the language must make sure that it happ ens like that

Two kinds of ob jects two kinds of links

Languages with one kind of link will typically have a delegation or parentof

link which implements sharing akin to inheritance Adding a second kind of link

suggests intro ducing a structural description link similar to the classof link In

traditional prototyp ebased languages each ob ject b eing oneofakind it gets

b oth its slot names and slot values When a large numb er of structurally identical

ob jects are created it b ecomes tempting to share the structural information a

line of reasoning that pushed the self team to invent maps

A mapbased language is constructed by making maps true ob jects Because

their slots contain indices to b e reinterpreted in the context of the receiver maps

as ob jects cannot answer messages So we make them abstract ob jects unable

to answer messages With maps represented as ob jects it b ecomes p ossible to

take advantage of them in the programming metho dology A mapbased language

encourages a programming metho dology where the notion of structurally similar

ob jects b ecomes very imp ortant In such a language we can sp eak ab out a group

of structurally identical ob jects Mapbased op erations to add or delete a slot to

all ob jects in a clone family etc should b e implemented

Two kinds of links one kind of ob ject

Typically a language with two kinds of links and one kind of ob ject can b e

obtained by some rationalization of a language with two kinds of ob jects and

two kinds of links For example consider the mapbased language prop osed

earlier Can we transform maps in order to make them standard ob jects capable

of answering messages without impairing the programming mo del The answer is

yes The problem with maps b egins when we send them messages whose result

needs a reinterpretation in the context of a concrete ob ject in order to make

sense But maps dont need to b e implemented like standard prototyp es A

simple idea illustrated in Figure is to replace the map by a descriptor ob ject

with one slot called slotsDict which p oints to an ob ject implementing a slot

dictionary The slot dictionary is not an ordinary prototyp e despite a similar yet

not identical asp ect in Figure but rather an ob ject similar to smalltalks

metho d dictionary We draw it as a b ox with round corners and it is actually an

ob ject answering athsome selectori returning its asso ciated value and athsome

selectori puthsome valuei messages like a smalltalk dictionary

The advantage of this representation is that now we can send legitimate

messages to descriptors namely slotsDict as well as to slot dictionaries In desc. desc. point desc. o1

10 o2 20

slotsDict 1 x 1 0 slots dict. for desc. y 2 0 display 3 add 4 slots dict. for point method for displaying points

method for adding points

Fig The p oint example using descriptors

fact our descriptors lo ok pretty much like smalltalk classes A descriptor

based language similar to the previous mapbased one can b e designed very

simply In order to preserve an ob jectcentered programming mo del descriptors

should b e created automatically like maps were Nonetheless descriptors are so

much like classes that we are at the frontier b etween abstractioncentered and

ob jectcentered programming here An imp ortant missing feature that makes

the language still promoting an ob jectcentered programming mo del is the lack

of a sharing mechanism b etween descriptors that would have a semantics similar

to inheritance By taking care not to intro duce such a link b etween descriptors

we dont encourage programmers to design their applications mainly around

descriptors see for more information ab out descriptors

But whats in a link

The characterization by the numb er of links is an imp ortant measure of the

complexity of a language but since this classication was rst published ex

amples have proved that the nature of these links is also imp ortant Amulet

for instance denes four dierent delegation semantics called mo des Clearly

classifying Amulet has having four kinds of links would bring little insight into

the nature of the language

This suggests another level of classication classifying the links themselves

We have identied two main family of links comparative links like delegation

inheritance etc and descriptive links isa classof mapof descriptorof etc

Other family of links could also b e added esp ecially reective links such as a

behaviorof found in reective languages Kinds of links ars therefore

b etter understo o d in our classication as kinds of families of links Objects + message sending + shallowClone

representation variables and methods slots

dynamic yes no yes no modification of structure

creation yes no yes no yes no yes no ex-nihilo L3 L6 L9 L12

creation newEmpty newInitials newEmpty newInitials newEmpty newInitials newEmpty newInitials primitive L1 L2 L4 L5 L7 L8 L10 L11

......

delegation implicit explicit implicit implicit

ObjectLispLike Act1Like ExemplarLike SelfLike

L1 L2 L1 possible extensions of L1 uninteresting language

L2 is reductible to L1 ... are not developed in this paper

Fig An historical taxonomy

Classifying Existing Languages

First classication based on primitives mechanisms

The taxonomy shown in Figure is extracted from and is only shown here to

give an historical p ersp ective that reects our understanding of prototyp ebased

languages at that time It takes into account how ob jects are represented

how they can b e created and mo died and the form of delegation implicit or

explicit prop osed by the language Four existing prototyp ebased languages were

classied in this taxonomy self objectlisp act and examplars

self and Ob jectLisp are memb ers of the language families L and L

resp ectively b oth extended with implicit delegation From the p oint of view of

that taxonomy they only dier in the representation of ob jects self uses slots

while objectlisp uses variables and metho ds examplars is b est characterized

by the family illustrated by L prototyp es have variables and metho ds the

structure of prototyp es cannot b e mo died dynamically new ob jects are created

ex nihilo or by copying existing ones the parent link is named sup erExemplar

and delegation is implicit along this link However since it is an hybrid language

11

This classication is also op erational one implemented as a smalltalk class hi

erarchy The hierarchy can b e used to interpret expressions of simulations of the

classied languages This smalltalk program named Prototalk is in fact a frame

work allowing to rapidly implement a simulation of any prototyp ebased language

also providing classes some of its characteristics are out of the scop e of our tax

onomy act describ ed in Section can b e attached sp ecic characteristics

Ob jects can have variables and a script Messages to ob jects are examined by the

script in which various actions can b e p erformed including explicit delegation

to other ob jects in the system When the script rejects a message there is an

implicit delegation to the parent of the receiver the script of which b eing in turn

executed These functionalities can b e classied in an extension of the language

L for which the evaluator is also able to deal with explicit delegation orders

Second classication based on the semantics of primitives

This section now prop oses a comparative table taking into account the whole

set of criteria presented in Section Most of the entries have b een explained

let us simply quote a few particularities

For what concerns the interpretation of the extension mechanism languages

such as garnet or yafool only prop ose the value sharing interpretation while

others such as self or objectlisp only prop ose the prop erty sharing one

Others such as newtonscript prop ose b oth by allowing to create the two

kind of extensions implemented by two links named proto or parent Another

approach encapsulated inheritance is prop osed by agora which p ermits each

ob ject to control the creation of its future extensions and the readwrite access

they will have on the attributes of the extended ob ject We have quoted

the advantages and drawbacks of b oth interpretations b esides mixed solutions

raise the issue of managing b oth kind of delegation links

Abstractionbased Classication

The gure summarizes our second classication We have represented ve

categories of languages four describ ed here with one example language in each

and one corresp onding to Wegners classless ob jectbased languages in which

he classies Ada The list of p ossible languages in each class is by no mean

closed For example another path towards a language with two kinds of ob jects

but one kind of link app ears when considering the status of prototypical ob

jects in Lieb ermans rst prop osal In Lieb ermans mind the standard way to

represent a concept is to provide a prototypical instance of this concept Clyde

is the prototypical elephant to which other ob jects of the same concept can

delegate for default prop erties Because mo difying a prototypical ob ject has an

imp ortant and often undesirable eect on all other ob jects delegating to it we

can make them immutable ob jects hence stressing their particular role In the

ClydeFred example Clyde would no longer b e mutable therefore making it

imp ossible to indirectly mo dify Fred by mutating Clyde A safe version of such a

language designed in this line provides another example of a language with two

kinds of ob jects and one kind of link

It is also worth noting that the classication using the numb er of kinds of

ob jects and links needs not to b e restricted to ob jectcentered languages We have

Self Object Lisp Garnet Amulet Agora Moostrap

KR ORE

Creation ex nihilo yes no yes no no yes

Cloning yes yes no no yes yes

Extension mechanism yes yes yes yes yes optional

Dynamic mo dication of yes yes yes yes no p ossible yes

ob ject structure at meta

level

Distinction b etween no yes no no yes no slots

variables et metho ds

Interpretation of exten prop erty prop erty value shar slot p er encapsulated prop erty

sion mechanism sharing sharing ing slot dier inheritance sharing

ent kinds of

sharing

Sharing mechanism delegation delegation delegation delegation delegation delegation

mixin

metho ds

based

Singlemultiple parents multiple single multiple simple simple simple or

mixins multiple

Dynamic inheritance yes yes no yes

Other language charac traits and inheritance inheritance inheritance reexive

teristics lobby based hierarchy hierarchy hierarchy kernel hall

organiza and com and traits

tion p osition

hierarchy

NewtonScript Kevo Omega Obliq Yafool

Creation ex nihilo yes no no yes yes

Cloning yes yes yes yes multiple yes

Extension mechanism yes no no no yes

Dynamic mo dication of yes yes yes for proto no yes

ob ject structure typ es no for

others

Distinction b etween no yes yes no no

variables et metho ds

Interpretation of exten prop erty shar typ elike shar value sharing

sion mechanism ing and value ing

sharing

Sharing mechanism delegation propagation propagation concatenation delegation

Simplemultiple parents double simple simple multiple multiple

Dynamic inheritance yes no

Other language charac inheritance comp osition typ e hierarchy aliases and Mo dels and in

teristics hierarchy and hierarchy and distributed stances

ROMdened clone families programming

prototyp es

Fig Languages comparison

already noted that our descriptorbased language is at the frontier of abstraction

centered programming If we take this language and add an inheritance link

b etween descriptors we end up having a language with one kind of ob jects but

three kinds of links parentof descriptorof and descriptor inheritance which

cannot b e characterized as ob jectcentered Moreover consider a language where

metaclasses are rstclass ob jects as Cointes Ob jVlisp Such a language has

two kinds of ob jects instances and classes since metaclasses are simply classes

whose instances are classes and two kinds of links instantiation and inheritance

However it is certainly not ob jectcentered We have used our classication to 2 kinds of objects - 2 kinds of links (Map-based programming)

2 kinds of objects - 1 kind of object - 1 kind of link 2 kinds of links (Trait-based (Descriptor-based programming) programming)

1 kind of object - 1 kind of link

(Lieberman's original)

1 kind of object - 0 kind of link

(Ada, following Wegner)

Fig The second classication with example languages

characterize ob jectcentered programming languages but it is not restricted to

this class of languages

An interesting work now is to assess existing languages in the light of our

classication For example in our view self is not prototyp ebased but it is cer

tainly ob jectcentered It is our opinion that using the notion of ob jectcentered

programming with abstract ob jects presented here the design of self can b e

p ositively enhanced Our preferred path of upgrade would b e to intro duce traits

as abstract ob jects like in Section but to make maps rstclass ob jects in the

line of our descriptors Section and This would make self a delegation

based programming language with two kinds of ob jects and two kinds of links

Persp ectives

A domain in order to b e considered mature must provide a comprehensive and

intelligible description of its basic principles its ro ots its foundations its alter

native designs and its concrete realizations It is our hop e that our work since

the b eginning of the nineties has help to convey p eople in the eld of prototyp e

based programming and their p otential users some of this deep understanding

To this end we have used traditional scientic pro cesses observation compar

ison and classication The two ma jor contributions are the two classications

which have clarify the design alternatives b ehind prototyp ebased languages

but also the richness of their dierent programming mo dels as well as their p osi

tion in the larger domain of ob jectoriented programming These contributions

complement existing work and esp ecially the Treaty of Orlando and Wegners

classication

Besides this classication eort our work has also op en some new research

p ersp ectives The explicit denition of the kinds of sharing lifetime and creation

time sharing achieved by cloning and delegation has shown that the two mech

anisms are irreducible to each other It has also led us to identify the problem

of self which o ccurs when frontiers b etween ob jects are blurred by teh sharing

of slot bindings b etween them In turn the self problem has led us to identify

on ma jor use of delegation which is to create split representations of domain

entity using rstclass split ob jects Split ob jects consider as a whole a set of

individual ob jects delegating to each other that represent one single domain en

tity The kind of sharing allowed by delegation gives unique prop erties to split

ob jects that make them esp ecially useful in ob jectoriented databases and other

p ersistent applications

A second p ersp ective is op en by our second classication We have intro duced

a general notion of ob jectcentered programming which admits some kinds of

abstract devices such as traits and maps provided that the programming mo del

is still dominated by the ob jectcentered subset of the language ie the ma jor

application design activity revolves around the creation of concrete ob jects By

recognizing the p otential for abstract ob jects dierent from classes yet capable

of structuring ob jectcentered programs we have reconcile prototyp es and ab

stractions Corollarily we have brought to the fore the existence of more and

more structured delegationbased languages forming a continuum b etween pure

prototyp ebased languages and classbased ones

For a long time prop onents of the prototyp ebased approach have suggested

software development metho dologies evolving from a lib eral designs using pro

totyp es towards a more a more structured one to end up with a completely

structured applications using classes Our work not only highlights the p oten

tial for several ob jectcentered programming mo dels but also suggest a concrete

path of evolution where prototyp ebased programs could b e turned into class

based ones by successive transformations from less structured to more structured

ob jectcentered programs

If prototyp ebased programming has still to nd its place in the realm of

software development it is our convictions that split ob jects and ob jectcentered

programming have an essential role to play in its future

References

O Agesen L Bak C Chamb ers BW Chang U Hlzle J Maloney RB Smith

D Ungar and M Wolczko The SELF Programmers Reference Manual Sun

Microsystems Inc and Stanford University

O Agesen L Bak C Chamb ers BW Chang U Hlzle J Maloney RB Smith

D Ungar and M Wolczko The SELF Programmers Reference Manual Sun

Microsystems Inc and Stanford University

Apple Computer Inc Macintosh Al legro Common Lisp Reference Manual Version

D Bardou and C Dony Split Ob jects A Disciplined Use of Delegation Within

Ob jects In Proceedings of OOPSLA Sans Jose California Special Issue of

ACM SIGPLAN Notices pages

G Blaschek ObjectOriented Programming With Prototypes SpringerVerlag

Berlin

DG Bobrow and T Winograd An Overview of KRL a Knowledge Representation

Language Cognitive Science

AH Borning The Programming Language Asp ects of ThingLab a Constraint

Oriented Simulation Lab oratory ACM Transactions on Programming Languages

and Systems

AH Borning Classes Versus Prototyp es in Ob jectOriented Languages In Procee

dings of the ACMIEEE Fal l Joint Computer Conference Montvale New Jersey

pages

RJ Brachman What ISA Is and Isnt An Analysis of Taxonomic Links in

Semantic Networks Computer

JP Briot Instanciation et heritage dans les langages objets These de ieme

cycle Universite de Paris Rapp ort LITP

L Cardelli A Language With Distributed Scop e Computing Systems

C Chamb ers Predicate Classes In O Nierstrasz editor Proceedings of Ecoop

Kaiserslautern Germany Lecture Notes in Computer Science pages

Berlin SpringerVerlag

C Chamb ers D Ungar BW Chang and U Holzle Parents are Shared Parts of

Ob jects Inheritance and Encapsulation in SELF LISP and Symbolic Computation

Craig Chamb ers David Ungar and Elgin Lee An ecient implementation of self

a dynamicallytyp ed ob jectoriented language based on prototyp es SIGPLAN

Notices Octob er

B Cohen and GL Murphy Mo dels of Concepts Cognitive Science

C Dony J Malenfant and D Bardou Les langages a prototyp es In R Ducour

nau J Euzenat and A Nap oli editors Langages et Modeles dObjets INRIA

Collection Didactique A paratre

C Dony J Malenfant and P Cointe Prototyp eBased Languages From a New

Taxonomy to Constructive Prop osals and Their Validation In A Paep cke editor

Proceedings of OOPSLA Vancouver Canada Special Issue of ACM SIGPLAN

Notices pages

Christophe Dony Prototalk A framework for the design and the op erational

evaluation of prototyp ebased languages Technical Rep ort LIRMM

SOUMIS PUBLICATION

R Ducournau Y YAFOOL le langage a objets et YAFEN linterface

graphique SEMA GROUP Montrouge

JD Ichbiah JGP Barnes JC Heliard B KriegBrueckner O Roubine and

BA Wichman Ada Reference Manual and Rationale for the Design of the Ada

Programming Language ACM SIGPLAN Notices

WR Lalonde Designing Families of Data Typ es Using Examplars ACM Trans

actions on Programming Languages and Systems

WR LaLonde DA Thomas and JR Pugh An Exemplar Based Smalltalk

In NK Meyrowitz editor Proceedings of OOPSLA Portland Oregon Special

Issue of ACM SIGPLAN Notices pages

H Lieb erman A Preview of Act AI Memo Articial Intelligence Lab oratory

Cambridge Massachusetts

H Lieb erman Using Prototypical Ob jects to Implement Shared Behavior in

Ob jectOriented Systems In Proceedings of OOPSLA Portland Oregon Spe

cial Issue of ACM SIGPLAN Notices pages

H Lieb erman Habilitation a diriger des recherches Memoire de synthese Uni

versite Pierre et Marie Curie Paris LITP Institut Blaise Pascal

J Malenfant On the Semantic Diversity of DelegationBased Programming Lan

guages In Proceedings of OOPSLA Austin Texas Special Issue of ACM SIG

PLAN Notices pages

J Malenfant Abstraction et encapsulation en programmation par prototyp es

Technique et science informatiques

J Malenfant Abstraction encapsulation et reexion dans les langages a prototypes

Habilitation a diriger des recherches Nantes University Technical Rep ort

INFO Ecole des mines de Nantes

G Masini A Nap oli D Colnet D Leonard and K Tombre Les langages a

objets InterEditions Paris

M Minsky A Framework for Representing Knowledge In P Winston editor The

Psychology of Computer Vision pages McGrawHill New York

P Mulet and P Cointe Denition of a Reective Kernel for a Prototyp eBased

Language In Proceedings of the st JSSST International Symposium on Object

Technologies for Advanced Software Lecture Notes in Computer Science

pages

Philipp e Mulet Reexion langages a prototypes These duniversite Universite

de Nantes

BA Myers DA Giuse RB Dannenb erg B Van der Zanden D Kosbie

E Previn A Mickish and P Marchal Garnet Comprehensive Supp ort for Graph

ical HighlyInteractive User Interfaces IEEE Computer

BA Myers DA Giuse and B Van der Zanden Declarative Programming

in a Prototyp eInstance System Ob jectOriented Programming Without Writing

Metho ds In A Paep cke editor Proceedings of OOPSLA Vancouver Canada

Special Issue of ACM SIGPLAN Notices pages

RB Rob erts and IP Goldstein The FRL Manual AI Memo Articial

Intelligence Lab oratory MIT Cambridge Massachusetts

R Smith The Alternate Reality Kit An Animated Environment for Creating

Interactive Simulations Proc of the IEEE Computer Society Workshop on

Visual Languages Dal las Texas pages June

RB Smith and D Ungar Programming as an Exp erience The Inspiration for Self

In Walter Oltho editor Proceedings of ECOOP Aarhus Denmark Lecture

Notes in Computer Science pages Berlin SpringerVerlag

WR Smith The Newton Application Architecture In Proceedings of the

th IEEE Computer Society International Conference San Francisco California

pages

LA Stein H Lieb erman and D Ungar A Shared View of Sharing The Treaty

of Orlando In W Kim and FH Lo chovsky editors ObjectOriented Concepts

Databases and Applications pages ACM PressAddisonWesley Reading

Massachusetts

P Steyaert Open Design of ObjectOriented Languages A Foundation for Spe

cialisable Reective Language Frameworks PhD thesis Vrije Universiteit Brussel

Belgium

A Taivalsaari Cloning Is Inheritance Computer Science Rep ort WP Univer

sity of Jyvaskyla Finland

A Taivalsaari A Critical View of Inheritance and Reusability in ObjectOriented

Programming PhD thesis University of Jyvaskyla Finland

A Taivalsaari Delegation Versus Delegation or Cloning Is Inheritance To o ACM

OOPS Messenger

D Ungar C Chamb ers BW Chang and U Hlzle Organizing Programs With

out Classes Lisp and Symbolic Computation

D Ungar and RB Smith Self The Power of Simplicity In NK Meyrowitz

editor Proceedings of OOPSLA Orlando Florida Special Issue of ACM SIG

PLAN Notices pages Also published in Lisp and Symb olic

Computation Kluwer Academic Publishers pages

P Wegner Dimensions of Ob jectBased Language Design In Proceedings of

OOPSLA Orlando Florida Special Issue of ACM SIGPLAN Notices

pages