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