Object-Oriented Programming © 2 July 2021 1 / 54 Object-Oriented Programming
Total Page:16
File Type:pdf, Size:1020Kb
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. -
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). -
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 . -
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. -
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. -
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. -
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 -
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. -
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. -
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 -
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. -
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.