DOCSLIB.ORG

Realization of Multimethods in Single Dispatch Object Oriented Languages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Realization of Multimethods in Single Dispatch Object Oriented Languages Realization of Multimethods in Single Dispatch Object Oriented Languages Rajeev Kumar, Vikram Agrawal and Anil Mangolia Department of Computer Science and Engineering Indian Institute of Technology Kharagpur Kharagpur, WB 721302, India [email protected] Abstract The need for multimethods is preeminent in the domain of object-oriented programming. However, multimethods are far from universally acknowledged. Commonly used languages – C++, Java & C# – are single dispatching languages. In this paper, we demonstrate the alternatives for multimethods in such languages. The techniques discussed, in this paper, include double dispatching (a well known technique), technique of message dispatching using RTTI (explored in detail by us in this paper), and reflection (a feature provided by some compilers). We implement these techniques for C++, Java and C# languages and discuss issues associated with encapsulating multimethods in single dispatch languages. We also compare techniques in terms of their efficiency, ease of (re)use and type safety. Keywords: object-oriented programming, message dispatch, single dispatch, multiple dispatch, multimethods. 1. Introduction Polymorphism is one of the central features of the object-oriented programming. Depending on the number of polymorphic arguments participating in method lookup, object-oriented languages can be classified into: (i) single dispatch languages where only receiver or one argument participates, and (ii) multiple dispatch languages where more than one argument participates. The methods with more than one polymorphic argument are called multimethods. Commonly used languages e.g., C++, C# and Java are single dispatch languages where as languages like Cecil [Cha92] and CLOS [Bob+88] are multiple dispatch languages. The need for multimethods expressed by the programs suggests inclusion of the multimethods in single dispatch languages. For example, following are few cases where this problem manifests itself in diverse applications: 1. A standard binary arithmetic such as Add(Operand o1, Operand o2) requires the message to be dispatched on both operands o1 and o2. If the data types supported are fixed-precision integers and floating-point numbers, the method for adding two fixed-precision integers is different from that for adding two floating numbers which in turn is different from that for mixed mode addition. Similarly, most data types define an equality testing binary operation and ordering relations. 2. The message PaisDo(Collection c1, Collection c2, Block b) takes the collections, c1 and c2, and a closure block b and iterates through the two collections in parallel. Neither collection is more important than the other is. However, in a single-dispatching language, the programmer has no choice but to favor one over the other. 3. In a graphics application, the message Display(Shape s, Device d) is intended to display a Shape s on an output Device d. However, drawing a rectangle is different from drawing a spline and an X-window screen uses a different rendering strategy for a filled polygon than does a fancy graphics accelerator. Thus, the exact method to be invoked depends upon both, the shape and the display device. There are two ways of adding multimethod support to a single dispatch language, one, make changes in language syntax and compiler, and, two, simulate realization of multimethods on the existing single dispatch languages indirectly. Simulation has advantage that no change is required in the compiler. In this paper, we discuss simulation of multimethods in single dispatch languages using the following three techniques: x Double dispatching – Single dispatching on each polymorphic arguments in turn, x Using runtime type identifiers – Using type of polymorphic arguments and method lookup routine in program, and x Reflection – Using named method invocation and changing message dispatch with computational reflection. ACM SIGPLAN Notices 18 Vol. 40(5), May 2005 The remainder of this paper is organized as follows. In Section 2, we briefly review the basics of object-oriented languages and the need of multimethods for elegant programming. In Section 3, we present how to realize multimethods in single dispatch languages. In Section 4, we discuss language features and their support in realizing multimethods. Finally, we conclude in Section 5. 2. Object Oriented Techniques 2.1 Preliminaries The mechanism for performing a task in object-oriented programming involves finding an appropriate agent termed as an object and giving to this agent a message that describes the request [Bud87, Str97]. The message is accompanied by the additional information needed to perform the action. The receiver is the agent to whom the message is sent. If the receiver accepts the message, it bears the responsibility to carry out the indicated action. In response to a message, the receiver executes some method to satisfy the request. The idea of message in object-oriented programming is closely associated with the concept of encapsulation or information hiding. A class t defines instance variables (or data members) and methods (or member functions) of some objects. Objects conforming to this definition are referred to as instances of the class. The notion of a class enables the programmer to describe the common features of a concept, while still allowing each object of the class to have a sense of the individuality. For example, a shape is a concept. We express the features of a shape by defining a shape class in Fig. 1. class Shape instance variables center : Point methods rotate(angle: integer) -- Rotate the shape by an angle end class Fig. 1: Definition of Shape class We may now create instances (i.e. objects) of the shape class. To perform the task of rotating a shape, we send the rotate message to the shape object that we wish to rotate. The additional information supplied is the angle by which the shape needs to be rotated. The methods of a class solely have privileged access to the instance variables of the class. Only the interface provided by the methods is externally visible. Thus, when a message is transmitted to a receiver, the sender does not really care how the request is processed. It is entirely the responsibility of the receiver to interpret the message and invoke the appropriate method to perform the desired action. On the other hand, an abstract class is a class of which there are no direct instances; it helps in abstraction and is used to create subclasses. With reference to the example in Fig. 1, it would be meaningless to create an instance of the shape class; a ‘shapeless’ shape is hardly of any use. It makes more sense to create an instance of a specific shape as a circle or a square. Knowledge of a more general class is also applicable to a more specific class through inheritance. A subclass or child class that extends a class or classes (called the superclasses or parent classes of the subclass), is said to inherit the attributes of its superclasses. Inheritance applies to the definitions of both instance variables and methods. Both instance variables and methods defined in a parent class become associated with a child class and are available for use by instances of the child class. For example, a circle is a shape, so is a square. Therefore, it is natural to express the circle and square classes as subclasses of the shape class. These classes are organized into a hierarchical inheritance structure. Such hierarchies are typical of object-oriented programming and can grow significantly largeer at times. The concept of inheritance not only enables to share common features, but also allows certain features to be overridden. A subclass can override the definitions of methods that it would otherwise inherit by redefining them. For example, the circle class provides its own rotate method, overriding the rotate method provided by the shape class. So does the square class. However, they both inherit other features from the shape class. Object-oriented programming speeds up the program development and improves the maintenance, reusability and modifiability of software if the object-oriented techniques are properly used. For example, a variable that is declared as a shape, during the course of execution, can take on many different forms, holding an instance of a circle at one instant, and an instance of a square at the other. This notion of accepting an instance of a class where an instance of its superclass is expected ACM SIGPLAN Notices 19 Vol. 40(5), May 2005 is called substitutability principle. By substitutability principle, an instance of a subclass can always be used in any context in which an instance of a superclass can be used, and this phenomenon triggers polymorphic behavior. Polymorphism is used to describe the notion that the type of a receiver is distinguished from the value that it holds at a particular instant. 2.2 Motivation for Multimethods We explain multimethods with reference to the example below. For simplicity, we assume the existence of only two kinds of shapes (viz. circle and square) in the inheritance hierarchy. class Shape -- An abstract class instance variables center : Point methods abstract draw(s :Shape) -- Draw shape s abstract intersect(s1:Shape, s2:Shape) -- Intersect shape s1 with shape s2 end class Fig. 2: Definition of Shape class using multimethod In most object oriented programming languages, a message is sent to one distinguished receiver object. The run-time type of the receiver determines the method that is invoked by the message. Other arguments of message (if any) are passed to the invoked method and thus, do not participate in method-lookup (also known as dispatching). This style of object-oriented programming is termed as single dispatching, since method-lookup is performed only with respect to the single receiver argument. Single dispatching works fine for many kinds of messages, especially those in which one argument is more special than the rest, in the sense that this argument alone determines the method to be involved.
Load more

Recommended publications
  • Dynamic Operator Overloading in a Statically Typed Language Olivier L
    Dynamic Operator Overloading in a Statically Typed Language Olivier L. Clerc and Felix O. Friedrich Computer Systems Institute, ETH Z¨urich, Switzerland [email protected], [email protected] October 31, 2011 Abstract Dynamic operator overloading provides a means to declare operators that are dispatched according to the runtime types of the operands. It allows to formulate abstract algorithms operating on user-defined data types using an algebraic notation, as it is typically found in mathematical languages. We present the design and implementation of a dynamic operator over- loading mechanism in a statically-typed object-oriented programming lan- guage. Our approach allows operator declarations to be loaded dynam- ically into a running system, at any time. We provide semantical rules that not only ensure compile-time type safety, but also facilitate the im- plementation. The spatial requirements of our approach scale well with a large number of types, because we use an adaptive runtime system that only stores dispatch information for type combinations that were encoun- tered previously at runtime. On average, dispatching can be performed in constant time. 1 Introduction Almost all programming languages have a built-in set of operators, such as +, -, * or /, that perform primitive arithmetic operations on basic data types. Operator overloading is a feature that allows the programmer to redefine the semantics of such operators in the context of custom data types. For that purpose, a set of operator implementations distinguished by their signatures has to be declared. Accordingly, each operator call on one or more custom-typed arguments will be dispatched to one of the implementations whose signature matches the operator's name and actual operand types.
    [Show full text]
  • Multimethods
    11-A1568 01/23/2001 12:39 PM Page 263 11 Multimethods This chapter defines, discusses, and implements multimethods in the context of Cϩϩ . The Cϩϩ virtual function mechanism allows dispatching a call depending on the dynamic type of one object. The multimethods feature allows dispatching a function call depending on the types of multiple objects. A universally good implementation requires language support, which is the route that languages such as CLOS, ML, Haskell, and Dylan have taken. Cϩϩ lacks such support, so its emulation is left to library writers. This chapter discusses some typical solutions and some generic implementations of each. The solutions feature various trade-offs in terms of speed, flexibility, and dependency management. To describe the technique of dispatching a function call depending on mul- tiple objects, this book uses the terms multimethod (borrowed from CLOS) and multiple dis- patch. A particularization of multiple dispatch for two objects is known as double dispatch. Implementing multimethods is a problem as fascinating as dreaded, one that has stolen lots of hours of good, healthy sleep from designers and programmers.1 The topics of this chapter include • Defining multimethods • Identifying situations in which the need for multiobject polymorphism appears • Discussing and implementing three double dispatchers that foster different trade-offs • Enhancing double-dispatch engines After reading this chapter, you will have a firm grasp of the typical situations for which multimethods are the way to go. In addition, you will be able to use and extend several ro- bust generic components implementing multimethods, provided by Loki. This chapter limits discussion to multimethods for two objects (double dispatch).
    [Show full text]
  • Multiple Dispatch and Roles in OO Languages: Ficklemr
    Multiple Dispatch and Roles in OO Languages: FickleMR Submitted By: Asim Anand Sinha [email protected] Supervised By: Sophia Drossopoulou [email protected] Department of Computing IMPERIAL COLLEGE LONDON MSc Project Report 2005 September 13, 2005 Abstract Object-Oriented Programming methodology has been widely accepted because it allows easy modelling of real world concepts. The aim of research in object-oriented languages has been to extend its features to bring it as close as possible to the real world. In this project, we aim to add the concepts of multiple dispatch and first-class relationships to a statically typed, class based langauges to make them more expressive. We use Fickle||as our base language and extend its features in FickleMR . Fickle||is a statically typed language with support for object reclassification, it allows objects to change their class dynamically. We study the impact of introducing multiple dispatch and roles in FickleMR . Novel idea of relationship reclassification and more flexible multiple dispatch algorithm are most interesting. We take a formal approach and give a static type system and operational semantics for language constructs. Acknowledgements I would like to take this opportunity to express my heartful gratitude to DR. SOPHIA DROSSOPOULOU for her guidance and motivation throughout this project. I would also like to thank ALEX BUCKLEY for his time, patience and brilliant guidance in the abscence of my supervisor. 1 Contents 1 Introduction 5 2 Background 8 2.1 Theory of Objects . 8 2.2 Single and Double Dispatch . 10 2.3 Multiple Dispatch . 12 2.3.1 Challenges in Implementation .
    [Show full text]
  • Redalyc.Attaining Multiple Dispatch in Widespread Object-Oriented
    Dyna ISSN: 0012-7353 [email protected] Universidad Nacional de Colombia Colombia Ortin, Francisco; Quiroga, Jose; Redondo, Jose M.; Garcia, Miguel Attaining multiple dispatch in widespread object-oriented languages Dyna, vol. 81, núm. 186, agosto, 2014, pp. 242-250 Universidad Nacional de Colombia Medellín, Colombia Available in: http://www.redalyc.org/articulo.oa?id=49631663031 How to cite Complete issue Scientific Information System More information about this article Network of Scientific Journals from Latin America, the Caribbean, Spain and Portugal Journal's homepage in redalyc.org Non-profit academic project, developed under the open access initiative Attaining multiple dispatch in widespread object-oriented languages Francisco Ortin a, Jose Quiroga b, Jose M. Redondo c & Miguel Garcia d a Computer Science Department, University of Oviedo, Spain, [email protected] b Computer Science Department, University of Oviedo, Spain, [email protected] c Computer Science Department, University of Oviedo, Spain, [email protected] d Computer Science Department, University of Oviedo, Spain, [email protected] Received: October 23th, de 2013. Received in revised form: April 28th, 2014. Accepted: May 22th, 2014 Abstract Multiple dispatch allows determining the actual method to be executed, depending on the dynamic types of its arguments. Although some programming languages provide multiple dispatch, most widespread object-oriented languages lack this feature. Therefore, different implementation techniques are commonly used to obtain multiple dispatch in these languages. We evaluate the existing approaches, presenting a new one based on hybrid dynamic and static typing. A qualitative evaluation is presented, considering factors such as software maintainability and readability, code size, parameter generalization, and compile-time type checking.
    [Show full text]
  • Understanding Symmetry in Object- Oriented Languages
    JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2003 Vol. 2, No. 5, September/October 2003 Understanding Symmetry in Object- Oriented Languages Liping Zhao, UMIST, U.K. James O. Coplien, North Central College, U.S.A. Abstract The success of symmetry applications in many scientific disciplines has motivated us to explore symmetry in software. Our exploration is based on an informal notion that symmetry is the possibility of making a change together with some aspect that is immune to this change. In this view, symmetry has a duality of change and constancy whereby some aspect of an object can be changed while leaving other key aspects invariant. This view of symmetry is a fundamental concept underpinning many symmetry principles in the physical sciences. We have found that we can explain some object-oriented language constructs using this notion of symmetry. This article explores symmetry in object-oriented languages and also provides other examples of symmetry outside of object-oriented programming to show that symmetry considerations broaden beyond object orientation to other areas of software design. 1 INTRODUCTION The success of symmetry applications in many scientific disciplines has motivated us to explore symmetry in software [7][8][31]. Our exploration is based on an informal notion that symmetry is the possibility of making a change while some aspect remains immune to this change. In this view, symmetry has a duality of change and constancy whereby some aspect of an object can be changed while leaving other key aspects invariant. This view of symmetry has underpinned many principles in the physical sciences.
    [Show full text]
  • Componentization: the Visitor Example
    Componentization: the Visitor example Bertrand Meyer* Karine Arnout** [email protected] [email protected] Chair of Software Engineering ETH (Swiss Federal Institute of Technology) Cite as follows: Bertrand Meyer, CH-8092 Zurich, Switzerland Karine Arnout, Componentization: http://se.ethz.ch The Visitor Example, to appear in Computer (IEEE), 2006. *Also Eiffel Software, California **Now at AXA Rosenberg, Orinda, California Abstract: In software design, laziness is a virtue: it’s better to reuse than to redo. Design patterns are a good illustration. Patterns, a major advance in software architecture, provide a common vocabulary and a widely known catalog of design solutions addressing frequently encountered situations. But they do not support reuse, which assumes components: off-the-shelf modules ready to be integrated into an application through the sole knowledge of a program interface (API). Is it possible to go beyond patterns by componentizing them — turning them into components? We have built a component library which answers this question positively for a large subset of the best- known design patterns. Here we summarize these results and analyze the componentization process through the example of an important pattern, Visitor, showing how to take advantage of object-oriented language mechanisms to replace the design work of using a pattern by mere “ready-to-wear” reuse through an API. The reusable solution is not only easier to use but more general than the pattern, removing its known limitations; performance analysis on a large industrial application shows that the approach is realistic and scales up gracefully. Keywords: Design patterns, Reuse, Components, Library design, Componentization 1.
    [Show full text]
  • Multiple Dispatching
    Multiple Dispatching Alex Tritthart WS 12/13 Outline 1 Introduction 2 Dynamic Dispatch Single Dispatch Double Dispatch 3 Multiple Dispatch Example 4 Evaluation 2 / 24 Introduction What is it all about? Assume c l a s s Animal f shout ( ) = 0g c l a s s Lion : Animal f shout ( ) f" r o a r "gg void shoutMethod(Animal &a)f a . shout ( ) g Call Lion lion(); shoutMethod(lion ); // should output "roar" 3 / 24 Introduction What do we need? We need no compiling time resolution, but runtime function resolution no function overloading, but function overriding This is called: Dynamic Dispatch 4 / 24 Introduction What do we need? We need no compiling time resolution, but runtime function resolution no function overloading, but function overriding This is called: Dynamic Dispatch 4 / 24 Dynamic Dispatch Dynamic Dispatch Decision at runtime Allows instance behaviour Implemented through virtual tables Dynamic Dispatch is every Dispatch with: More than one possibility Same method signature in super class and subclasses Choosing method depending on the real types of arguments There exist single dispatch, double dispatch, triple dispatch, ... 5 / 24 Dynamic Dispatch Single Dispatch Single Dispatch Definition "The Object-Oriented term for overriding, allowing different methods to be used depending on the type of a single object." 6 / 24 Dynamic Dispatch Single Dispatch Single Dispatch Dynamic dispatch with a single type Used mostly in object oriented languages Simple to implement Languages Java, C#, JS, Python, Ruby can handle single dispatch 7 / 24 Dynamic
    [Show full text]
  • Signature Redacted Department of Electrical Engineering and Computer Science May 20, 2015
    ARCHNES Abstraction in Technical Computing MASSACHUSETTS INSTITUTE OF TECHNOLOLGY by JUL 0 7 2015 Jeffrey Werner Bezanson LIBRARIES A.B., Harvard University (2004) S.M., Massachusetts Institute of Technology (2012) Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of Doctor of Philosophy at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY June 2015 @ Massachusetts Institute of Technology 2015. All rights reserved. Author....... Signature redacted Department of Electrical Engineering and Computer Science May 20, 2015 Certified by ............ Signature redacted ......... Alan Edelman Professor Thesis Supervisor Accepted by...... Signature redacted -6 Leslie Kolodziejski Chairman, Department Committee on Graduate Students 2 Abstraction in Technical Computing by Jeffrey Werner Bezanson Submitted to the Department of Electrical Engineering and Computer Science on May 20, 2015, in partial fulfillment of the requirements for the degree of Doctor of Philosophy Abstract Array-based programming environments are popular for scientific and technical computing. These systems consist of built-in function libraries paired with high-level languages for in- teraction. Although the libraries perform well, it is widely believed that scripting in these languages is necessarily slow, and that only heroic feats of engineering can at best partially ameliorate this problem. This thesis argues that what is really needed is a more coherent structure for this func- tionality. To find one, we must ask what technical computing is really about. This thesis suggests that this kind of programming is characterized by an emphasis on operator com- plexity and code specialization, and that a language can be designed to better fit these requirements.
    [Show full text]
  • Oomatch: Pattern Matching As Dispatch in Java
    OOMatch: Pattern Matching as Dispatch in Java by Adam Richard A thesis presented to the University of Waterloo in fulfilment of the thesis requirement for the degree of Master of Mathematics in Computer Science Waterloo, Ontario, Canada, 2007 c Adam Richard 2007 AUTHOR’S DECLARATION FOR ELECTRONIC SUBMISSION OF A THESIS I hereby declare that I am the sole author of this thesis. This is a true copy of the thesis, including any required final revisions, as accepted by my examiners. I understand that my thesis may be made electronically available to the public. ii Abstract We present a new language feature, specified as an extension to Java. The feature is a form of dispatch, which includes and subsumes multimethods (see for example [CLCM00]), but which is not as powerful as general predicate dispatch [EKC98]. It is, however, intended to be more practical and easier to use than the latter. The extension, dubbed OOMatch, allows method parameters to be specified as patterns, which are matched against the arguments to the method call. When matches occur, the method applies; if multiple methods apply, the method with the more specific pattern overrides the others. The pattern matching is very similar to that found in the “case” constructs of many functional languages (ML [MTHM97], for example), with an important difference: functional languages normally allow pattern matching over variant types (and other primitives such as tuples), while OOMatch allows pattern matching on Java objects. Indeed, the wider goal here is the study of the combination of functional and object-oriented programming paradigms. Maintaining encapsulation while allowing pattern matching is of special impor- tance.
    [Show full text]
  • Object-Oriented Programming
    Programming Languages Third Edition Chapter 5 Object-Oriented Programming Objectives • Understand the concepts of software reuse and independence • Become familiar with the Smalltalk language • Become familiar with the Java language • Become familiar with the C++ language • Understand design issues in object-oriented languages • Understand implementation issues in object- oriented languages Programming Languages, Third Edition 2 1 Introduction • Object-oriented programming languages began in the 1960s with Simula – Goals were to incorporate the notion of an object, with properties that control its ability to react to events in predefined ways – Factor in the development of abstract data type mechanisms – Crucial to the development of the object paradigm itself Programming Languages, Third Edition 3 Introduction (cont’d.) • By the mid-1980s, interest in object-oriented programming exploded – Almost every language today has some form of structured constructs Programming Languages, Third Edition 4 2 Software Reuse and Independence • Object-oriented programming languages satisfy three important needs in software design: – Need to reuse software components as much as possible – Need to modify program behavior with minimal changes to existing code – Need to maintain the independence of different components • Abstract data type mechanisms can increase the independence of software components by separating interfaces from implementations Programming Languages, Third Edition 5 Software Reuse and Independence (cont’d.) • Four basic ways a software
    [Show full text]
  • Efficient Multimethods in a Single Dispatch Language
    Efficient Multimethods in a Single Dispatch Language Brian Foote, Ralph E. Johnson and James Noble Dept. of Computer Science, University of Illinois at Urbana-Champaign 201 N. Goodwin, Urbana, IL 61801, USA [email protected] [email protected] School of Mathematical and Computing Sciences, Victoria University of Wellington P.O. Box 600, Wellington, New Zealand [email protected] Abstract. Smalltalk-80 is a pure object-oriented language in which messages are dispatched according to the class of the receiver, or first argument, of a message. Object-oriented languages that support multimethods dispatch messages using all their arguments. While Smalltalk does not support multimethods, Smalltalk's reflective facilities allow programmers to efficiently add them to the language. This paper explores several ways in which this can be done, and the relative efficiency of each. Moreover, this paper can be seen as a lens through which the design issues raised by multimethods, as well as by using metaobjects to build them, can be more closely examined. 1. Introduction The designers of object-oriented languages usually consider multimethods and single dispatch to be competing alternatives. This paper describes a variety of ways to implement multimethods in single-dispatch languages such as Smalltalk. It is not surprising that multimethods can be implemented in Smalltalk, because it is a reflective language that has been extended in many ways. However, it is surprising how well multimethods can work with single dispatch. This paper develops a simple extended syntax that makes it easy to mix multimethods and normal methods. The semantics of multimethods are simple, they have no syntactic or performance cost if they are not used, they interoperate well with Smalltalk's metaobjects, and they are as efficient to execute as comparable hand-written code.
    [Show full text]
  • Multijava: Design Rationale, Compiler Implementation, and Applications
    MultiJava: Design Rationale, Compiler Implementation, and Applications Curtis Clifton, Todd Millstein, Gary T. Leavens, and Craig Chambers TR #04-01b December 2004 Revised version of TR #04-01, dated January 2004 and titled MultiJava: Design Rationale, Compiler Implementation, and User Experience Keywords: Open Classes, Open Objects, Extensible Classes, Extensible Exter- nal Methods, External Methods, Multimethods, Generic Functions, Object-oriented Programming Languages, Single Dispatch, Multiple Dispatch, Encapsulation, Mod- ularity, Static Typechecking, Subtyping, Inheritance, Java Language, MultiJava Language, Separate Compilation 2002 CR Categories: D.3.1 [Programming Techniques] Object-oriented Pro- gramming; D.3.2 [Programming Languages] Language Classifications — object- oriented languages; D.3.3 [Programming Languages] Language Constructs and Fea- tures — abstract data types, classes and objects, control structures, inheritance, modules, packages, patterns, procedures, functions and subroutines; D.3.4 [Pro- gramming Languages] Processors — compilers; D.3.m [Programming Languages] Miscellaneous — generic functions, multimethods, open classes. Copyright c 2004, Curtis Clifton, Todd Millstein, Gary T. Leavens, and Craig Chambers, Submitted for Publication. Department of Computer Science 226 Atanasoff Hall Iowa State University Ames, Iowa 50011-1040, USA MultiJava: Design Rationale, Compiler Implementation, and Applications CURTIS CLIFTON Iowa State University TODD MILLSTEIN University of California, Los Angeles GARY T. LEAVENS Iowa State University and CRAIG CHAMBERS University of Washington MultiJava is a conservative extension of the Java programming language that adds symmetric multiple dispatch and open classes. Among other benefits, multiple dispatch provides a solution to the binary method problem. Open classes provide a solution to the extensibility problem of object-oriented programming languages, allowing the modular addition of both new types and new operations to an existing type hierarchy.
    [Show full text]