Generalized Message Passing in a Virtual Reality Application

David Flater

February

Abstract

The message passing semantics of an ob jectoriented programming language is one of the

factors that determines howpowerful the language is Whether it is referred to as a metho d

invo cation a dispatching call an event a signal or something else each ob jectoriented

programming language supp orts some op eration that is similar in eect to message passing

What diers from language to language is the semantics of that message passing These seman

tics largely determine the degree to which an ob jectoriented language supp orts p olymorphis m

overloading typ e checking and abstraction

Although it is theoretically p ossible to implementanygiven applicati on in any computa

tionally complete language the exibili ty of the language that is used will in practice havea

great inuence over the shap e of the nal pro duct Those features that are extremely dicult

to implement in the language b eing used are less likely to b e implemented If the pro ject is

one where the choice of programming language is not as imp ortant as the quality of the nal

pro duct such as in a researchenvironment then it is wise to investigate the alternatives

Virtual reality is one research applicatio n that can easily b e hamp ered by the limitations

inherent in a programming language We dene the concepts of recipient resolution and action

resolution discuss their application to virtual reality and suggest an approach for extending

Ob jective C to supp ort them

Intro duction

It is generally considered to b e desirable for a programmer to b e able to concentrate on the highlevel

structure of a program separate from the messy implementation details Ob jectoriented program

ming languages oer ways of structuring programs that help to achieve that goal By supp orting

p olymorphism dynamic binding and dynamic typ e checking they give the programmer the ability

to state more concisely the highlevel b ehavior of the program

One may think of routines in a program as having a kind of signaltonoise ratio that is the

numb er of statements that say what needs to b e done divided bythenumb er of statements that

sayhow to do it Co de with a high signaltonoise ratio is readable and intuitive co de with a low

signaltonoise ratio is cryptic A statement that is part of the signal of a given subroutine may

b ecome noise if it is moved up into the main program since it b elongs in the subroutine

As the exibility of the programming language decreases the signaltonoise ratio of programs

written in that language tends to decrease as well For example consider the case of translating

a C virtual function call into C The programmer must either set up p ointers to the correct

functions and make the function call via a p ointer or co de up a decision tree at the p oint of call to

select among the p ossible functions Either way the added co de is pure noise

Our goal is to improve the signaltonoise ratio of programs with particular attention to the vir

tual reality VR class of applications To do that wemake the programming language more exible

and provide greater supp ort for encapsulating co de in the ob ject to which it p ertains However we

must rst examine the various levels of exibility supp orted by existing programming languages in

order to b etter understand the extensions that can b e made

Typ es of Dispatching

Each programming language comes with its own vo cabulary and set of concepts When one p erson

thinks of sending a message another thinks of invoking a metho d In this pap er we will concentrate

on the message passing paradigm since our generalized semantics are most naturally expressed in

that paradigm

The generality of the message passing semantics which corresp onds to how exible the message

passing is when it is used by a programmer is limited byhow the compiler and runtime environment

dispatchdeliver messages to their recipients Existing programming languages supp ort dierent

kinds of dispatching but the dierences are not always obvious when terms such as dynamic

binding are used lo osely In order to avoid ambiguities in terminologywe make the following

denitions

NonDispatching

Nondispatching languages have static typ e checking and static binding The message and

the sp ecic class of the recipient the receiving ob ject must b oth b e known at compile time

These languages are not very interesting for ob jectoriented programming since only the most

basic forms of p olymorphism eg function name overloading can b e supp orted Cisan

example of a nondispatching language

Sub class Dispatching

Sub class dispatching is static typ e checking with dynamic binding A message can b e sent

to an ob ject without knowing the sp ecic class of that ob ject provided that it is known to

b e derived from or identical to a parent class that is sp ecied at compile time The message

handler the function that is invoked when the message is received sometimes called a method

or a member function is determined at run time since sub classes can override the message

handlers of their parents C supp orts sub class dispatching

Classless Dispatching

Classless dispatching requires dynamic typ e checking if anytyp e checking is done and dy

namic binding It is p ossible to op erate generically over all ob jects and all messages A message

can b e sent without knowing the name of the message or the identity or class of the recipient

at compile time The compiler can no longer guarantee that the recipient of a message will

b e able to handle it so runtime failures are p ossible However there are fewer restrictions

on how the programmer must construct the class hierarchy for a given program Ob jectiveC

supp orts classless dispatching

It is imp ortant to understand the dierence b etween supp orting an application and merely en

abling it Since all the programming languages mentioned b elow are computationally complete they

all enable the same set of programs to b e written However writing VR applications in a language

that has restrictive message passing semantics is substantially more dicult than writing them in

a more exible language Where the user of a language with classless dispatching simply p erforms

a single function call the user of a statically b ound language mightneedtowritepagesofcodeto

achieve the same eect Those features that are extremely dicult to implement in the language

b eing used are less likely to b e implemented so it is b etter to use a language that provides support

for the desired application

With its revision Ada now supp orts sub class dispatching Tagged typ es provide the

functionality of sub classes and a dispatching call is similar in eect to sending a message to an

ob ject without knowing its sp ecic class The parent class must still b e sp ecied at compile time

The rst Ada standard was nondispatching

Dynamic typ e checking requires eachobjecttohave a tag that tells the runtime environment what its typ e is

Statically typ ed languages determine all typ es at compile time so the typ es are implicit at run time

Static binding implies that a function invo cation in the source co de maps to exactly one function With dynamic

binding there may b e several candidate functions and one of them is selected when the invo cation is executed

Ada is a registered trademark of the US Government Ada Joint Program Oce

C supp orts sub class dispatching that is the same as Adas only the syntax and the termi

nology are dierent A virtual function call in C is the same as a dispatching call in Ada

Ob jective C supp orts classless dispatching The data typ e id indicates an ob ject in the generic

sense it is not necessary to sp ecify the class of the recipient of a message at compile time The

p erform message is used to achieve the eect of sending a message whose name is not known

until run time The following sample written in the GNU dialect of Ob jective C demonstrates

the sending of a message that is sp ecied at run time to an ob ject whose class is unsp ecied in the

function sendsomemessagetosomeobject

include stdioh

include objcObjecth

implementation Thing Object

void mess

puts Thing instance got mess

end

implementation Thing Object

void mess

puts Thing instance got mess

end

void

sendsomemessagetosomeobject

id recipient char message

The perform message and the

selgetanyuid function are both

defined by the compiler

recipient perform

selgetanyuid message

main

char messname

int choice

id somethingorother

puts Enter name of message

gets messname

puts Enter number of object

scanf d choice

if choice

somethingorother Thing new

else

somethingorother Thing new

sendsomemessagetosomeobject

somethingorother messname

exit

Certain software packages are identied in this pap er to foster understanding Suchidentication do es not imply

recommendation or endorsementby the National Institute of Standards and Technology nor do es it imply that the

packages identied are necessarily the b est available for the purp ose

Here is a sample run of the ab ove program

Enter name of message

mess

Enter number of object

Thing instance got mess

The program will fail at run time if the sp ecied message cannot b e handled bythechosen ob ject

Enter name of message

mess

Enter number of object

error Thing instance

Thing does not recognize mess

IOT trapAbort

It will also fail if the user typ es the name of a message that is not declared in the program or in

the Ob jective C library

Although there havebeenmany ob jectoriented languages over the years and several of great

historical imp ortance that wehave not discussed the languages already mentioned suce to demon

strate the ma jor forms of dispatching currently supp orted

Generalized Dispatching

The word resolution is most often used to refer to the pro cess of cho osing the most appropriate

version of an overloaded function or cho osing the correct metho d for the sp ecic sub class in a

sub class dispatching language There are several p ossible matches for a message name and it is

up to the compiler or runtime environment to nd the b est matchHowever it is p ossible to

use b est match resolution more extensively The following three generalized forms of dispatching

supp ort b est match resolution that is not restricted to name resolution

Recipient Resolution

A message can b e directed at a group of recipients and received by only the b est one Best

is determined at run time using evaluation functions Recipient resolution is routing that is

supp orted by the programming language instead of implemented by the programmer Recipient

resolution provides supp ort for automatically using the b est to ol for a particular job

Message Resolution

A group of messages can b e directed at a single recipient and only the b est one sent Message

resolution provides supp ort for automatically cho osing the b est way to use a particular to ol We

will not discuss message resolution in detail since it is less interesting than recipient resolution

and is a sp ecial case of action resolution

Action Resolution

Action resolution combines recipient resolution with message resolution Action resolution

supp orts goalbased programming and can abstract out the common task of searching for the

b est next move

The selection of the b est recipient or b est course of action is done by using evaluation func

tions Evaluation functions are dened by the programmer to compute or estimate or sp ecify the

desirability of sending a particular message to a particular recipient relative to the other p ossible

combinations An evaluation function for generalized dispatching serves somewhat the same purp ose

as the evaluation function in a b estrst search

Sub class and classless dispatching can b e viewed as cases of recipient resolution in which the

evaluation functions are solely based on the classes and sub classes the numb er of parameters and

their data typ es True recipient resolution gives the programmer the p ower to dene dispatching

priorities explicitly instead of b eing restricted to a single languagedep endentevaluation function

The programmers evaluation function can b e time and situationdep endent and can use anyavailable

input

To clarify the semantics of recipient and action resolution we dene an action to b e the sending

of a sp ecic message to a sp ecic ob ject The message sent is one of a set of messages M and the

ob ject is one of a set of p ossible recipients R Recipient resolution requires that M have only one

memb er action resolution do es not

The selection of a single action to p erform out of all the p ossible combinations of messages and

recipients is done bycho osing the combination that maximizes the value of an evaluation function

f This value is called the priority of the action f is a function of a message manobject r and

the global state S S is meant to incorp orate all other p ossible inputs to the evaluation function

including message parameters global variables timedep endent information and data received from

remote sources If more than one p ossible action has the maximum priority then the choice among

the winners can b e made arbitrarily by the runtime environment However one of the winning

actions must b e taken issuing an error is not p ermissible

Although it is ne in theory to have a single evaluation function that calculates priorities for

all actions in practice it is not very useful In practice wewillwanttohave a set of evaluation

functions F such that either m or r has b een made implicit and the corresp onding parameter

omitted from each function call The message or recipient is made implicit by encapsulating the

evaluation function inside the message or ob ject to which it relates

The two approaches make m implicit or make r implicit are equivalent in the sense that b oth

can b e trivially transformed into the single monolithic evaluation function approach However they

are vastly dierent in practice It would make little sense for messages to encapsulate evaluation

functions in an environment that supp orts only recipient resolution Since it is the recipient not the

message that is b eing resolved it is only logical for the evaluation functions to b e encapsulated by

the recipients That way the evaluation functions can b e understo o d by the programmer as dening

the b ehaviors of the recipients with resp ect to the messages that mightbereceived

It is not as obvious what the right approach is when action resolution is fully supp orted and

resolving actions can b e a twodimensional problem However since there is more context asso ciated

with an ob ject than with a message it would still make more sense to asso ciate evaluation functions

with recipients than with messages If desired one can always get back to the single monolithic

evaluation function byhaving each ob ject p ointtoit

Extending Ob jectiveC

Although wehave not actually implemented a compiler for a language that do es recipient or ac

tion resolution wehave considered how Ob jectiveCmight b e extended to provide the additional

functionality with minimal disruption of its presentsyntax

To get started we dene an evaluation function in the toplevel Ob ject class to b e inherited by

all ob jects The name priority will henceforth b e reserved for evaluation functions By default

ob jects will disqualify themselves from action resolution by returning a negative priority regardless

of the action

float priority char message

int parmc

void parmv

In dening the language we sp ecify neither determinacy nor randomness in this case the results are

implementationdep endent

return

When action resolution is p erformed the dispatcher will never cho ose an action that has a

negative priority If all p ossible actions have a negative priority then a ag is set to indicate that

the message could not b e sent Section gives an example of why abnormal termination of the

program at this p oint is not an acceptable alternative

An evaluation function for a regular class of ob jects could then b e done similar to the following

example

Evaluation function for legal dept

float priority char message

int parmc

void parmv

Messages taking one argument

if parmc

if strcmp message sue

Wont sue other lawyers

if parmv isKindOf

Lawyer class

return

else

return

if strcmp message threaten

return

Pass the buck for inherited methods

return super priority message

parmc

parmv

To group recipients and messages we assume the existence of a Bag class that acts as a container

for ob jects Such a class is provided by the GNU Ob jective C Class Library lib ob jects

id recipients Bag new

addElement legaldept

addElement publicrelationsdept

addElement president

addElement spy

So far wehave done nothing that violates normal Ob jectiveCsyntax but nowwe come to the

turning p oint The following syntax is already dened in Ob jective C to mean that wewant to send

a message to the Bag ob ject itself rather than to one of the ob jects that it contains

recipients threaten rivalcompany

We will therefore invent a new op erator to indicate that wewanttocho ose the b est recipient out

of the Bag

recipients threaten rivalcompany

In order to do action resolution wemust rst decide what it means to have a Bag of messages

Messages in Ob jective C are not ob jects one cannot simply throw a handful of them into a Bag

However we can achieve the same result using message selectors or message names

To emphasize that the Bag must contain only messages we dene a MessageBag sub class that

allows messages to b e added and removed by giving their names

interface MessageBag Bag

addMessage char message

removeMessage char message

end

The message names or selectors would b e bagged using metho ds inherited from the parent class

Whether the messages are actually bagged by name or by selector do es not matter although it may

b e advantageous to verify that the named message do es exist b efore it is bagged

Now that wehave MessageBags we can do full action resolution

id messages MessageBag new

addMessage sue

addMessage threaten

addMessage conciliate

addMessage bash

addMessage observe

recipients messages rivalcompany

Generalized Dispatching and Virtual Reality

Recipient Resolution

When building a virtual world wewant to b e able to create rob ots A VR rob ot is an active

intelligententity within the virtual world that is controlled by the computer Programming sucha

rob ot is often a lab orious and dicult task b ecause of the many details that must b e handled The

programmer must try to think of every p ossible situation that the rob ot could encounter and add

co de to handle each one

Consider the example of a rob ot trying to op en a lo cked do or Without recipient resolution the

programmer must add co de to the rob ot to decide which to ol to use at what time and for how long

BOOL openlockeddoor door

int timeavailable

id tool

assert timeavailable

Try to open the door with the key

if tool self findinventory key

if tool opendoor door

return TRUE

if timeavailable

return FALSE

Either didnt have key or it didnt work

Try to card the door

if tool self findinventory card

if tool opendoor door

return TRUE

if timeavailable

return FALSE

Getting desperate

If door is wooden try the axe for a while

if door isKindOf WoodenDoor class

if tool self findinventory axe

int a

for aaa

if tool opendoor door

return TRUE

if timeavailable

return FALSE

Try to burn our way in with propane torch

if tool self findinventory torch

while tool haspropane

door islocked

if tool opendoor door

return TRUE

if timeavailable

return FALSE

Unable to open door

return FALSE

This approach is inherently clumsy b ecause we are attempting to preeducate the rob ot with

knowledge ab out every single to ol it mightencounter If we later create a new to ol wemust also

up date the rob ots program or else the rob ot will not knowwhentousethetool

With recipient resolution it is not necessary to preeducate the rob ot The usefulness of a given

to ol for a given task will b e co ded into the to ol itself where it b elongs The rob ot will then b e able

to pick up a new to ol and recognize its usefulness without b eing reeducated

BOOL openlockeddoor door

int timeavailable

assert timeavailable

for timeavailable

door islocked timeavailable

inventory opendoor door

return door islocked

Note that the clumsiness asso ciated with limiteduse to ols has gone away When the fuel for the

torch is used up the torchs evaluation function b egins returning a negative priority and the rob ot

stops trying to use the torch Similarly the priority of the axe will decrease each time it fails to

op en the do or It will always b e negative if the do or is not wo o den Dep ending on how smart we

want the rob ot to seem the key and the card can either refuse to b e used on the same do or more

than once or refuse to b e used on the wrong do or in the rst place Although the total number of

lines of co de mighthave increased b ecause of the need for priority functions the toplevel routine

is much more straightforward and the detail work has b een moved into the lower levels where it

b elongs

In recentyears VR has b een redened by some to refer to the sophisticated graphics that can

complement a virtual world rather than the virtual world itself Fortunately recipient resolution

can b e applied in many dierent domains including graphics

Supp ose that we are designing a graphics engine that must render images of many ob jects in real

time Some of them are constantly moving rotating and changing some do not move unless they

are acted up on by another ob ject and some are simply backdrop Once an ob ject has b een rendered

the rendering can b e drawn and redrawn with relative ease the exp ensive part is rerendering ob jects

that havemoved or changed so that the picture will lo ok right At the same time as this rendering

is taking place wemust also handle input from the user and compute the b ehaviors of the ob jects

in real time In order to keep up with all the computation that needs to b e done wemust make

intelligent decisions ab out when to rerender ob jects A half second delay in up dating the rendering

of a slowly moving ob ject will b e considerably less noticeable than a half second delay in up dating

the rendering of an ob ject that is ying around However if the fast moving ob ject collides with

the slowly moving one wemust devote a large time slice to b oth of them to make the collision lo ok

right

Writing a main lo op for this graphics engine that do es not just rely on brute force to keep up with

the work load could b e a very dicult task However with recipient resolution we can implement

a complete task scheduler just by dening the priority function The main lo op could b e as simple

as this

while

world render

The evaluation functions would adjust the priorityupward as the sp eed of the ob ject and the

age of the rendering increased Also included in the world would b e a sp ecial ob ject tasked with

pro cessing user input and sending heartb eat messages to ob jects to make them lo ok aliveand

react to their surroundings It is an unfortunate kluge that the render message is delib erately

misused to insure that events unrelated to rendering user input and heartb eats will b e serviced

In the next section wewillseehow this inelegance is removed by the more exible action resolution

Action Resolution

Recipient resolution takes for granted that weknowwhich is the b est course of action ie which

message to send to achieve our goal This is not always the case Let us return to our rst example

in whichwewere simulating a company trying to deal with a threat p osed byarival company

With recipient resolution if we assume that the b est resp onse to a threat is a counterthreat wecan

delegate the decision of who is b est to make the counterthreat However if wewanttobeableto

cho ose b etween legal action threats diplomacyPRwars and watchful waiting wemust add co de

at the top level

With action resolution all of the information needed to cho ose a course of action is encapsulated

in the denitions of the ob jects so the programmer is free to delegate the decision making to the

run time environment Since lawyers can threaten and conciliate as well as sue the public relations

department can either threaten or conciliate and the president can threaten conciliate or bash

the decision making is not a linear pro cess It is necessary to weigh the risks and b enets of each

course of action knowing that the eectiveness of each course of action is aected by the to ol that

is used and the threat that is b eing dealt with The risks and b enets may also change over time

if while observing the threat the corp orate spy discovers evidence of wrongdoing that can b e used

against the threat the companymight decide to take legal action on the next iteration of the lo op

Of course the programmer is not at the mercy of the machine any more than he or she wants to

b e since decisions can still b e hard co ded

if threat isKindOf

Hostiletakeover class

company buybackstock

If wenow return to the graphics example we nd that there is no longer a need for a kluge to

p oll user input and broadcast heartb eat messages These actions can simply b e resolved against the

rendering work

id animate MessageBag new

Render draw objects

addMessage render

Let objects be active

addMessage heartbeat

Poll user input

addMessage userinput

while

world animate

Instead of relying on a sp ecial ob ject to p erio dically send heartb eats to every ob ject in the

world wenow let ob jects sp ecify a priority for their own heartb eat Dierent ob jects can nowhave

dierent heart rates Although we still need someb o dy to b e resp onsible for p olling user input we

no longer need to bind this unrelated action to the render message The ob jects that cannot receive

the userinput message simply return a negative priority

Exp eriments with Recipient Resolution

The idea for recipient and action resolution came from Cheezmud an exp erimental mud written

in Ob jectiveCAmud is a virtual world in whichanynumb er of users can interact with each other

and with characters rob ots run by the computer Cheezmud is copyrighted software that was

develop ed indep endently and placed under the GNU Public License

The virtual world can haveany theme wechose to use the traditional swords and sorcery theme

in our exp eriments Since Ob jective C do es not supp ort recipient resolution or action resolution

we settled for emulating recipient resolution via message routingasshown in the app endix This

was sucient to discover the manyways in whichevaluation functions simplify the task of VR

programming Not only are they useful for abstracting out the complex decision trees that computer

controlled characters mighthave needed they also p ermit usercontrolled characters to exhibit a

certain level of common sense in following the users commands

One ma jor example is the kill command In a swords and sorcery mud combat is a frequent

o ccurrence and weap ons are plentiful The emulated recipient resolution of Cheezmud allows the

computercontrolled characters to displayintelligence in their choice of weap onryWhenacharacter

do es a command the message in this case kill is resolved against the characters inventory the

ob jects that he or she is carrying the ro om that the character is in and the character himself

herself This is b ecause commands can b e related to to ols that are b eing carried unlo ck do or to

a lo cation go north or to the character grin The character has an inherent kill metho d that

corresp onds to unarmed combat most weap ons have kill metho ds with a higher priority

The default priority of the kill metho d for a weap on is calculated when the sp eed and maximum

damage done bytheweap on are set

speed s

damage d

tspeed floats

prio floatdamage tspeed

The result is a ranking of weap ons by their eectiveness such that the rate at which damage is

done and the amount of damage that can b e done at one time are b oth taken into consideration

This is merely a default evaluation function a more complex function that returns dierent priorities

dep ending on the nature of the enemy can easily b e sp ecied for a sp ecic sub class of weap on

Characters will then use the weap on that is b est suited for the sp ecic threat b eing faced when

dierent kinds of weap ons are b est suited for dierent kinds of enemies

The p ower of recipient resolution b ecame particularly obvious when we created a singleuse

weap on a b omb that explo des when thrown at an enemyAny computercontrolled character that

p ossesses it knows to use the b omb rst then nish o a surviving enemy with some other weap on

It was not necessary to add co de to test for the sp ecial weap on Its evaluation function returns a

high priority but it vanishes after one use The next time the character do es the kill command

it is resolved against his or her remaining inventory and the ght go es on without interruption

Another interesting application of evaluation functions was for containers suchassacks or bags

Acharacter can carry more items if he or she bags them up In Cheezmud a player that has more

than one sack can simply bag something without sp ecifying whichsack to use Items are trivially

distributed among all available sacks by dening evaluation functions that return a variable priority

for the bag command dep ending on how full the sack is

if contents count capacity

return

floatcapacity contents count

floatcapacity

Note that returning when the bag is full prevents anything else from b eing stued into it If

the player attempts to execute a bag command with all bags full an error is returned This is

an example of why abnormal termination of the program should not result if all p ossible recipients

have negative priority Ideally all languages would supp ort Ada or SQLlike exception handling

and we could simply write an exception handler for this case Instead Cheezmud uses the return

co de of the message routing routine to indicate success or failure

From these examples it is p ossible to see how helpful it would b e to have recipient or action

resolution for virtual reality programming The eort of writing evaluation functions is negligible

compared to the convenience of abstracting out so many sp ecial cases from the main program

Conclusion

Recipient resolution and action resolution provide supp ort for new styles of programming By moving

evaluation criteria away from the main program and abstracting out the search pro cess we state

more concisely the task that is to b e accomplished and thus increase the signaltonoise ratio of the

source co de

Future progress in exible programming languages may o ccur as the result of p ersistent pro

gramming Persistent languages allow programs to preserveinternal state indenitely and increase

supp ort for dynamic linking and dispatching so that previously compiled mo dules can work with

newly compiled mo dules without themselves having b een recompiled An example is E a p er

sistentversion of C While languages like E are adding database functions to programming

languages database languages are closing the gap in the other direction SQL has achieved com

putational completeness with the addition of Persistent Stored Mo dules and the control statements

that were necessary for PSM to b e useful SQL is now exploring new territory with its function

call semantics Given sucient metadata a program can use a SELECT statement to searchatrun

time for mo dules appropriate to a particular task and invoke them dynamically The designers of

standard SQL are b eing careful to preserve the safety and compilability of the language so certain

opp ortunities for even greater exibilityhave b een foregone That leaves op en the p ossibility for

exp erimentation with wilder variants of SQL that do more work at run time Overload resolution

could b e done at the last minute so that the b est matching function would always b e the one that is

called even if the CALL statementwere compiled and the b est matching function were dened dy

namically just now Exception handlers could recover from failures by calling the next b est function

from the list of candidate functions

The most eective programming can only b e done if the language p ermits the programmer to

express his or her intentions in a way that seems natural and intuitive Lower software qualityand

longer development times result if it is necessary to reformulate ideas in an awkward way to get them

implemented Language designers always run the risk of making a language that seems intuitiveand

natural to them but not to anyone else Hop efully the language extensions that wehave made will

not fall into that category

App endix

The following metho d resolves the recipient of the message generated when a character tries to do

something in Cheezmud Our denitions of recipient resolution and action resolution were only

made after Cheezmud was develop ed so the word action is used lo osely in this example Note

howthecharacter the characters lo cation and the characters inventory contents are searched

for appropriate message handlers NULL is returned if the recipient cannot b e resolved

resolveaction char action

int numargs

id actor NULL

float prio tprio

void countprio id whatever

if tprio whatever priority

action numargs prio

if tprio

prio tprio

actor whatever

countprio self

if location

countprio location

if self isKindOf Container class

self contents withObjectsCall

countprio

return actor

The actual sending of the message is done one level up in a metho d called do The following

is the relevant co de fragment

if t self resolveaction

verb numargs

char temp

sprintf temp s verb

if numargs

strcat temp

a selgetanyuid temp

if numargs

t perform a with self

else

t perform a with self with dobj

return

References

Gordon Blair John Gallagher David Hutchison and Doug Shepherd editors ObjectOriented

Languages Systems and Applicationschapter page Halsted Press New York

Ada HTMLHyp ertext Reference Manual URLhttpwwwadahomecomrm

United States Department of Defense Reference Manual for the Ada Programming Language

US Government Printing Oce Washington DC

Margaret A Ellis and Bjarne Stroustrup The AnnotatedCReferenceManual Addison

Wesley Reading MA

Dennis de Champ eaux Douglas Lea and Penelop e Faure ObjectOriented System Development

chapter page AddisonWesley Reading MA

Eugene Charniak Christopher K Riesb eck Drew V McDermott and James R Meehan Arti

cial Intel ligenceProgramming page Lawrence Erlbaum Asso ciates Hillsdale NJ second

edition

Cheezmud an exp erimental mud implemented in Ob jectiveC URLhttpwwwuniverse

digexnetdavelescheezmudtgz

ISOANSI working draft Database Language SQL SQL March XH XH

Murali Vemulapati Ram D Sriram and Amar Gupta Incremental loading in the p ersistent

C language E Journal of ObjectOrientedProgramming

About the author David Flater is a Computer Scientist in the Information Management Group

of the NIST Computer Systems Laboratory The National Institute of Standards and Technology is

an agency of the Technology Administration US Department of Commerce