DOCSLIB.ORG

O O S E E Object Orientation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
O O S E E Object Orientation Classification [7] O OSE E + classes + inheritance Object Orientation object−based class−based object−oriented Operating-System Engineering Operating-System Engineering — Object Orientation 2 Object-Oriented Design [2] Object-Based • implies the capability of data abstraction { methods provide access to attributes method { attributes represent instance variables Object-oriented design is a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and attribute • methods define the object’s external interface object physical as well as static and dynamic models of the systems under design. { similar to an abstract data type (ADT) • objects are unique instances, having only in common the need for memory Operating-System Engineering — Object Orientation 1 Operating-System Engineering — Object Orientation 3 Class-Based Object Orientation = Objects + Classes + Inheritance • objects are instances of classes • an object-oriented programming language must provide linguistic support { a class defines a set of common properties methods { properties are attributes of a class { it must enable the programmers to describe common properties of objects { classes may be compared to types ∗ such a language is referred to as an object-based programming language { it is called object-oriented only if class hierarchies can be built by inheritance ∗ • a meta-description specifies the interface instances so that the objects can be instances of classes that have been inherited { it allows the modeling of an object as a polymorphous entity { describing a uniform management class { indicating further data abstractions • object orientation is unattainable using imperative programming languages1 • depending on the programming language employed, a class may be an ADT 1Notwithstanding, from time to time there are comments stating the development of object-oriented systems using e.g. the C programming language. This is in contradiction to the classical definition of object orientation [7]. Operating-System Engineering — Object Orientation 4 Operating-System Engineering — Object Orientation 6 Object-Oriented Synonyms of the \Theory of Heredity" • implies the composition of abstract data types on the basis of inheritance base class ............ derived class { new classes are constructed by the reuse of (an) existing class(es) superclass ............ subclass { properties of the existing class(es) are inherited to the new class parent class ............ child class { a new class adds properties and/or redefines inherited properties inheriting class ............ inherited class • objects instantiated from classes composed in that way are polymorphous common class ............ specialized class { according to the class hierarchy, a single object relates to several classes { the object will be type compatible to more than one class “upper class” ............ “lower class” • inheritance allows for the specialization of the inherited class(es) Operating-System Engineering — Object Orientation 5 Operating-System Engineering — Object Orientation 7 Distinctness of Heredity Multiple Inheritance • a class is derivable from many base classes • inheritance appears in various shapes and is of different consequences: { many sets of attributes to inherit Foo Bar { single inheritance .....................................................9 { method redefinition/overloading is crucial { multiple inheritance ..................................................10 { classes can be inherited several times Foobar Fop ∗ multiple inclusion ..................................................11 ∗ sharing ............................................................12 • the class hierarchy may be deep and wide single inheritance path Foobarfop { a concept for implementation unification • any of these kinds serves the construction of a class hierarchy • brings about better reusability at the expense of an efficient implementation { class reuse is still limited to the very base class, but there are many of which Operating-System Engineering — Object Orientation 8 Operating-System Engineering — Object Orientation 10 Single Inheritance Multiple Inheritance Multiple Inclusion • a class is derivable from only one base class fragments { only a single set of attributes to inherit Foo base class Fop Fop Foobar object Fop Foo Fop Bar { method redefinition/overloading is simple fop foo Bar derived class base class Foo Bar • fop the class hierarchy is narrow but may be deep bar { a derived class may serve as a base class Foobar derived class Foobar foobar • brings about fairly efficient implementations at the expense of reusability • the attributes of classes inherited several times are included several times { class reuse implies composition, method redefinition, and kind of delegation { only the very base class appears to be reusable without any add-to • the final object contains copies of object fragments of the same class Operating-System Engineering — Object Orientation 9 Operating-System Engineering — Object Orientation 11 Multiple Inheritance Sharing Object Layout this-Polymorphism fragments this Fop Fop Fop Fop Foobar object Fop Foo Bar fop* foo object Foo Bar Fop* Foo* Foobar* Foo Bar fop* 0 fop bar foo Bar* Fop* Foobar foobar Foobar fop bar fop foobar N−1 • the attributes of classes inherited several times are included once only • from Foobar to Foo::Fop ⇒ this remains unchanged • the final object contains copies of pointers to the shared object fragment(s) • from Foobar to Bar::Fop ⇒ this +=sizeof(Foo) Operating-System Engineering — Object Orientation 12 Operating-System Engineering — Object Orientation 14 Object Layout Object Layout this-Adjustment foo__6Foobar: • Foo is on the single inheritance path: this pass through pushl 4(%esp) call foo__3Foo • addl $4711,%eax a method applied to an object is implicitly supplied with the object’s address addl $4,%esp f ret 2 class Foobar : public Foo, public Bar { within the single inheritance path, this is identical for all the classes int foo () f { taking multiple inheritance branches into account, this becomes variable return Foo::foo() + 4711; bar__6Foobar: g movl 4(%esp),%eax testl %eax,%eax ................................... jne .L4 • multiple inheritance may entail pointer manipulation upon method invocation int bar () f xorl %eax,%eax return Bar::bar() + 42; jmp .L5 .p2align 4,,7 { from derived to base class: adding some delta g g .L4: → ; addl $4,%eax { from base to derived class: subtracting some delta p. 16 .L5: pushl %eax call bar__3Bar • Bar is a multiple inheritance branch: (cond.) adjustment addl $42,%eax 2In C++, the pointer to the instance of a class (i.e., object) the invoked method is actually applied to. addl $4,%esp ret Operating-System Engineering — Object Orientation 13 Operating-System Engineering — Object Orientation 15 Late Binding Late Binding C++ → x86 • the compiler implements the common model fb: • .zero 8 the association at runtime of which method is going to be applied to an object . { treats all virtual methods identical . { the object’s methods are bound at the point in time of object instantiation movl $_vt$6Foobar$3Bar,fb+4 movl $_vt$6Foobar,fb . 3 • for methods to be capable of late binding, three preconditions must hold: Foobar fb; .................................................. fb: .zero 8 . 1. they must have been defined in (the external interface of) a base class, • the compiler implements the thunk model . 2. the method’s base class(es) must be inherited by some derived class(es), movl $__vt_6Foobar,fb { gives priority to the single inheritance path movl $__vt_6Foobar.3Bar,fb+4 3. and they must be redefined by the derived class(es) . { handicaps multiple inheritance branches . • also called dynamic binding—but must not be mixed up with dynamic loading 3gcc -O6 -S -fno-rtti -fno-exceptions -fomit-frame-pointer Operating-System Engineering — Object Orientation 16 Operating-System Engineering — Object Orientation 18 Late Binding C++ Case Study Late Binding Method Redefinition f f class Foo class Foobar : public Foo, public Bar int Foobar::foo () f foo__6Foobar: f public: int foo () return 4711; ........................................................ movl $4711,%eax virtual int foo () = 0; return 4711; g ret g; g int Foobar::bar () f bar__6Foobar: f f class Bar int bar () return 42; ........................................................ movl $42,%eax return 42; public: g; ret virtual int bar () = 0; g g; g; • the generated code is the same for the common model and the thunk model int foobar (Foo* fp, Bar* bp) f return fp->foo() + bp->bar(); • that a method is subjected to late binding is transparent to the method itself g; Foobar fb; Operating-System Engineering — Object Orientation 17 Operating-System Engineering — Object Orientation 19 Late Binding Common Model (1) Late Binding Thunk Model (1) • • every class containing a virtual function has a _vt$6Foobar: every class containing a virtual function has a virtual-function table virtual-function table of “call descriptors” .value 0 .value 0 { of function pointers __vt_6Foobar: { atripleofoffset, ?, and function pointer .long 0 .long 0 .value 0 .long 0 class Foobar : public Foo, public Bar f .value 0 .long foo__6Foobar class Foobar : public Foo, public Bar f int foo (); .long foo__6Foobar .................... int foo (); int bar (); .............................. __vt_6Foobar.3Bar: int bar (); g; _vt$6Foobar$3Bar: .long -4 g; .value -4 .long 0 .value 0 • thunks relate to multiple inheritance branches .long __thunk_4_bar__6Foobar
Load more

Recommended publications
  • Open WATCOM Programmer's Guide
    this document downloaded from... Use of this document the wings of subject to the terms and conditions as flight in an age stated on the website. of adventure for more downloads visit our other sites Positive Infinity and vulcanhammer.net chet-aero.com Watcom FORTRAN 77 Programmer's Guide Version 1.8 Notice of Copyright Copyright 2002-2008 the Open Watcom Contributors. Portions Copyright 1984-2002 Sybase, Inc. and its subsidiaries. All rights reserved. Any part of this publication may be reproduced, transmitted, or translated in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without the prior written permission of anyone. For more information please visit http://www.openwatcom.org/ Portions of this manual are reprinted with permission from Tenberry Software, Inc. ii Preface The Watcom FORTRAN 77 Programmer's Guide includes the following major components: · DOS Programming Guide · The DOS/4GW DOS Extender · Windows 3.x Programming Guide · Windows NT Programming Guide · OS/2 Programming Guide · Novell NLM Programming Guide · Mixed Language Programming · Common Problems Acknowledgements This book was produced with the Watcom GML electronic publishing system, a software tool developed by WATCOM. In this system, writers use an ASCII text editor to create source files containing text annotated with tags. These tags label the structural elements of the document, such as chapters, sections, paragraphs, and lists. The Watcom GML software, which runs on a variety of operating systems, interprets the tags to format the text into a form such as you see here. Writers can produce output for a variety of printers, including laser printers, using separately specified layout directives for such things as font selection, column width and height, number of columns, etc.
    [Show full text]
  • COMPILING FUNCTIONAL PROGRAMMING CONSTRUCTS to a LOGIC ENGINE by Harvey Abramson and Peter Ludemann Technical Report 86-24 November 1986
    COMPILING FUNCTIONAL PROGRAMMING CONSTRUCTS TO A LOGIC ENGINE by Harvey Abramson and Peter Ludemann Technical Report 86-24 November 1986 Compiling Functional Programming Constructs to a Logic Engine Harvey Abramson t and Peter Ltidemann:I: Department of Computer Science University of British Columbia Vancouver, B.C., Canada V6T 1W5 Copyright © 1986 Abstract In this paper we consider how various constructs used in functional programming can be efficiently translated to code for a Prolog engine (designed by Ltidemann) similar in spirit but not identical to the Warren machine. It turns out that this Prolog engine which contains a delay mechanism designed to permit co­ routining and sound implementation of negation is sufficient to handle all common functional programming constructs; indeed, such a machine has about the same efficiency as a machine designed specifically for a functional programming language. This machine has been fully implemented. t Present address: Department of Computer Science, Bristol University, Bristol, England . f Present address: IBM Canada Ltd., 1 Park Centre, 895 Don Mills Road, North York, Ontario, Canada M3C 1W3 The proposals for combining the two paradigms Compiling Functional Programming have been roughly classified in [BoGi86] as being Constructs to a Logic Engine either functional plus logic or logic plus functional. Harvey Abramson t and Peter Ltidemanni In the former approach, invertibility, nondeterminism Department of Computer Science and unification are added to some higher order functional language; in the latter approach, first-order University of British Columbia functions are added to a first-order logic with an Vancouver, B.C., Canada V6T lWS equality theory. We do not take any position as to Copyright© 1986 which approach is best, but since a logic machine already deals with unification, nondeterminism and invertibility, we have taken, from an implementation Abstract viewpoint, the logic plus functional approach.
    [Show full text]
  • Parameter Passing, Generics, Exceptions
    Lecture 9: Parameter Passing, Generics and Polymorphism, Exceptions COMP 524 Programming Language Concepts Stephen Olivier February 12, 2008 Based on notes by A. Block, N. Fisher, F. Hernandez-Campos, and D. Stotts The University of North Carolina at Chapel Hill Parameter Passing •Pass-by-value: Input parameter •Pass-by-result: Output parameter •Pass-by-value-result: Input/output parameter •Pass-by-reference: Input/output parameter, no copy •Pass-by-name: Effectively textual substitution The University of North Carolina at Chapel Hill 2 Pass-by-value int m=8, i=5; foo(m); print m; # print 8 proc foo(int b){ b = b+5; } The University of North Carolina at Chapel Hill 3 Pass-by-reference int m=8; foo(m); print m; # print 13 proc foo(int b){ b = b+5; } The University of North Carolina at Chapel Hill 4 Pass-by-value-result int m=8; foo(m); print m; # print 13 proc foo(int b){ b = b+5; } The University of North Carolina at Chapel Hill 5 Pass-by-name •Arguments passed by name are re-evaluated in the caller’s referencing environment every time they are used. •They are implemented using a hidden-subroutine, known as a thunk. •This is a costly parameter passing mechanism. •Think of it as an in-line substitution (subroutine code put in-line at point of call, with parameters substituted). •Or, actual parameters substituted textually in the subroutine body for the formulas. The University of North Carolina at Chapel Hill 6 Pass-by-name array A[1..100] of int; array A[1..100] of int; int i=5; int i=5; foo(A[i], i); foo(A[i]); print A[i]; #print A[6]=7
    [Show full text]
  • The Power of Interoperability: Why Objects Are Inevitable
    The Power of Interoperability: Why Objects Are Inevitable Jonathan Aldrich Carnegie Mellon University Pittsburgh, PA, USA [email protected] Abstract 1. Introduction Three years ago in this venue, Cook argued that in Object-oriented programming has been highly suc- their essence, objects are what Reynolds called proce- cessful in practice, and has arguably become the dom- dural data structures. His observation raises a natural inant programming paradigm for writing applications question: if procedural data structures are the essence software in industry. This success can be documented of objects, has this contributed to the empirical success in many ways. For example, of the top ten program- of objects, and if so, how? ming languages at the LangPop.com index, six are pri- This essay attempts to answer that question. After marily object-oriented, and an additional two (PHP reviewing Cook’s definition, I propose the term ser- and Perl) have object-oriented features.1 The equiva- vice abstractions to capture the essential nature of ob- lent numbers for the top ten languages in the TIOBE in- jects. This terminology emphasizes, following Kay, that dex are six and three.2 SourceForge’s most popular lan- objects are not primarily about representing and ma- guages are Java and C++;3 GitHub’s are JavaScript and nipulating data, but are more about providing ser- Ruby.4 Furthermore, objects’ influence is not limited vices in support of higher-level goals. Using examples to object-oriented languages; Cook [8] argues that Mi- taken from object-oriented frameworks, I illustrate the crosoft’s Component Object Model (COM), which has unique design leverage that service abstractions pro- a C language interface, is “one of the most pure object- vide: the ability to define abstractions that can be ex- oriented programming models yet defined.” Academ- tended, and whose extensions are interoperable in a ically, object-oriented programming is a primary focus first-class way.
    [Show full text]
  • The Principles of Object-Oriented Javascript Zakas
    TAKETAKE CONTROLCONTROL OFOF Foreword by Cody Lindley, Best-selling Author and Principal Frontend Architect JAVASCRIPT THE PRINCIPLES OF OBJECT-ORIENTED JAVASCRIPT JAVASCRIPT THE PRINCIPLES OF OBJECT-ORIENTED JAVASCRIPT THETHE PRINCIPLESPRINCIPLES OFOF OBJECTSOBJECTS at TandemSeven OBJECT-ORIENTEDOBJECT-ORIENTED If you’ve used a more traditional object-oriented • How to define your own constructors JAVASCRIPTJAVASCRIPT language, such as C++ or Java, JavaScript probably • How to work with and understand prototypes doesn’t seem object-oriented at all. It has no concept of classes, and you don’t even need to define any • Inheritance patterns for types and objects objects in order to write code. But don’t be fooled — The Principles of Object-Oriented JavaScript will leave NICHOLAS C. ZAKAS JavaScript is an incredibly powerful and expressive even experienced developers with a deeper understand- object-oriented language that puts many design ing of JavaScript. Unlock the secrets behind how objects decisions right into your hands. work in JavaScript so you can write clearer, more In The Principles of Object-Oriented JavaScript, flexible, and more efficient code. Nicholas C. Zakas thoroughly explores JavaScript’s object-oriented nature, revealing the language’s A B O U T T H E A U T H O R unique implementation of inheritance and other key characteristics. You’ll learn: Nicholas C. Zakas is a software engineer at Box and is known for writing on and speaking about the latest • The difference between primitive and reference in JavaScript best practices. He honed his experience values during his five years at Yahoo!, where he was principal • What makes JavaScript functions so unique frontend engineer for the Yahoo! home page.
    [Show full text]
  • Evolution and Composition of Object-Oriented Frameworks
    Evolution and Composition of Object-Oriented Frameworks Michael Mattsson University of Karlskrona/Ronneby Department of Software Engineering and Computer Science ISBN 91-628-3856-3 © Michael Mattsson, 2000 Cover background: Digital imagery® copyright 1999 PhotoDisc, Inc. Printed in Sweden Kaserntryckeriet AB Karlskrona, 2000 To Nisse, my father-in-law - who never had the opportunity to study as much as he would have liked to This thesis is submitted to the Faculty of Technology, University of Karlskrona/Ronneby, in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Engineering. Contact Information: Michael Mattsson Department of Software Engineering and Computer Science University of Karlskrona/Ronneby Soft Center SE-372 25 RONNEBY SWEDEN Tel.: +46 457 38 50 00 Fax.: +46 457 27 125 Email: [email protected] URL: http://www.ipd.hk-r.se/rise Abstract This thesis comprises studies of evolution and composition of object-oriented frameworks, a certain kind of reusable asset. An object-oriented framework is a set of classes that embodies an abstract design for solutions to a family of related prob- lems. The work presented is based on and has its origin in industrial contexts where object-oriented frameworks have been developed, used, evolved and managed. Thus, the results are based on empirical observations. Both qualitative and quanti- tative approaches have been used in the studies performed which cover both tech- nical and managerial aspects of object-oriented framework technology. Historically, object-oriented frameworks are large monolithic assets which require several design iterations and are therefore costly to develop. With the requirement of building larger applications, software engineers have started to compose multiple frameworks, thereby encountering a number of problems.
    [Show full text]
  • Obstacl: a Language with Objects, Subtyping, and Classes
    OBSTACL: A LANGUAGE WITH OBJECTS, SUBTYPING, AND CLASSES A DISSERTATION SUBMITTED TO THE DEPARTMENT OF COMPUTER SCIENCE AND THE COMMITTEE ON GRADUATE STUDIES OF STANFORD UNIVERSITY IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY By Amit Jayant Patel December 2001 c Copyright 2002 by Amit Jayant Patel All Rights Reserved ii I certify that I have read this dissertation and that in my opin- ion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. John Mitchell (Principal Adviser) I certify that I have read this dissertation and that in my opin- ion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. Kathleen Fisher I certify that I have read this dissertation and that in my opin- ion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. David Dill Approved for the University Committee on Graduate Studies: iii Abstract Widely used object-oriented programming languages such as C++ and Java support soft- ware engineering practices but do not have a clean theoretical foundation. On the other hand, most research languages with well-developed foundations are not designed to support software engineering practices. This thesis bridges the gap by presenting OBSTACL, an object-oriented extension of ML with a sound theoretical basis and features that lend themselves to efficient implementation. OBSTACL supports modular programming techniques with objects, classes, structural subtyping, and a modular object construction system. OBSTACL's parameterized inheritance mechanism can be used to express both single inheritance and most common uses of multiple inheritance.
    [Show full text]
  • Programming Languages
    ◦ ◦◦◦ TECHNISCHE UNIVERSITAT¨ MUNCHEN¨ ◦◦◦◦ ◦ ◦ ◦◦◦ ◦◦◦◦ ¨ ¨ ◦ ◦◦ FAKULTAT FUR INFORMATIK Programming Languages Multiple Inheritance Dr. Axel Simon and Dr. Michael Petter Winter term 2012 Multiple Inheritance 1 / 29 Outline Inheritance Principles 1 Interface Inheritance 2 Implementation Inheritance 3 Liskov Substition Principle and Shapes C++ Object Heap Layout 1 Basics 2 Single-Inheritance Excursion: Linearization 3 Virtual Methods 1 Ambiguous common parents 2 Principles of Linearization C++ Multiple Parents Heap Layout 3 Linearization algorithm 1 Multiple-Inheritance 2 Virtual Methods 3 Common Parents Discussion & Learning Outcomes Multiple Inheritance 2 / 29 “Wouldn’t it be nice to inherit from several parents?” Multiple Inheritance Inheritance Principles 3 / 29 Interface vs. Implementation inheritance The classic motivation for inheritance is implementation inheritance Code reusage Child specializes parents, replacing particular methods with custom ones Parent acts as library of common behaviours Implemented in languages like C++ or Lisp Code sharing in interface inheritance inverts this relation Behaviour contract Child provides methods, with signatures predetermined by the parent Parent acts as generic code frame with room for customization Implemented in languages like Java or C# Multiple Inheritance Inheritance Principles 4 / 29 Interface Inheritance DropDownList refresh() ActionObserver MyDDL changed() changed() Multiple Inheritance Inheritance Principles 5 / 29 Implementation inheritance PowerShovel FrontLoader actuate() actuate()
    [Show full text]
  • Approaches to Composition and Refinement in Object-Oriented Design
    Approaches to Composition and Refinement in Object-Oriented Design Marcel Weiher Matrikelnummer 127367 Diplomarbeit Fachbereich Informatik Technische Unversitat¨ Berlin Advisor: Professor Bernd Mahr August 21, 1997 Contents 1 Introduction 4 1.1 Object Orientation 4 1.2 Composition and Refinement 5 2 State of the Art 7 2.1 Frameworks 7 2.1.1 Framework Construction 8 2.1.2 Reusing Frameworks 9 2.2 Design Patterns 10 2.2.1 Reusing Patterns 10 2.2.2 Communicating Patterns 12 2.3 Commentary 13 3 Enhanced Interfaces 14 3.1 Interface Typing 14 3.2 The Refinement Interface 15 3.2.1 Protocol Dependencies 15 3.2.2 Reuse Contracts 18 3.3 Interaction Interfaces 21 3.3.1 Interaction Protocols 21 3.3.2 Protocol Specification and Matching 22 3.4 Commentary 23 4 Orthogonalization 24 4.1 Delegation 24 4.1.1 Prototypes Languages 25 4.1.2 Composition Filters 25 4.2 Mixins 27 4.2.1 Mixins and Multiple Inheritance 28 4.2.2 Nested Dynamic Mixins 28 4.3 Extension Hierarchies 29 4.3.1 Extension Operators 29 4.3.2 Conflicts: Detection, Resolution, Avoidance 30 4.4 Canonic Components 31 4.4.1 Components 31 4.4.2 Views 32 4.5 Commentary 33 1 5 Software Architecture 34 5.1 Architectural Styles 34 5.1.1 Pipes and Filters 35 5.1.2 Call and Return 36 5.1.3 Implicit Invocation 36 5.1.4 Using Styles 37 5.2 Architecture Description Languages 38 5.2.1 UniCon 38 5.2.2 RAPIDE 39 5.2.3 Wright 40 5.2.4 ACME 43 5.3 Commentary 43 6 Non-linear Refinement 45 6.1 Domain Specific Software Generators 45 6.1.1 A Domain Independent Model 46 6.1.2 Implementation 47 6.2 Subject Oriented
    [Show full text]
  • Object Oriented Languages
    Object oriented languages dr inż. Marcin Pietroń Object oriented programming • Object languages: - Java (business applications, mobile software etc.) - C++ (embedded, real-time, finance- sector) - Python (prototyping, testing) - Smalltalk - Ruby (web) - Objective-C (mobile) - … Object oriented programming • programming paradigm - data structures called "objects", contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods. Object oriented programming • a feature of objects is that an object's procedures can access and often modify the data fields of the object with which they are associated, • in OO programming, objects in a software system interact with one another. Object oriented programming • There is significant diversity in object-oriented programming, but most popular languages are class-based, meaning that objects are instances of classes, which typically also determines their type. Object oriented programming Languages that support object-oriented programming use inheritance for code reuse and extensibility in the form of either classes or prototypes. Those that use classes support two main concepts: • Objects - structures that contain both data and procedures • Classes - definitions for the data format and available procedures for a given type or class of object; may also contain data and procedures (class methods) Object oriented programming • Objects sometimes correspond to things found in the real world (e.g. a graphics program may have objects such as „figure ", "circle ", "square" or " cursor ", online shop may have objects such as "shopping cart" "customer" " basket " or "product ", • Objects can represent more abstract things and entities, like an object that represents an open file, or an object which provides some service (e.g.
    [Show full text]
  • Subroutines and Control Abstraction8 8.3.2 Call by Name
    Subroutines and Control Abstraction8 8.3.2 Call by Name Call by name implements the normal-order argument evaluation described in Section 6.6.2. A call-by-name parameter is re-evaluated in the caller’s referencing environment every time it is used. The effect is as if the called routine had been textually expanded at the point of call, with the actual parameter (which may be a complicated expression) replacing every occurrence of the formal parameter. To avoid the usual problems with macro parameters, the “expansion” is defined to include parentheses around the replaced parameter wherever syntactically valid, and to make “suitable systematic changes” to the names of any formal parame- ters or local identifiers that share the same name, so that their meanings never conflict [NBB+63, p. 12]. Call by name is the default in Algol 60; call by value is available as an alternative. In Simula call by value is the default; call by name is the alternative. Toimplement call by name,Algol 60 implementations pass a hidden subroutine that evaluates the actual parameter in the caller’s referencing environment. The hidden routine is usually called a thunk.2 In most cases thunks are trivial. If an actual parameter is a variable name, for example, the thunk simply reads the EXAMPLE 8.68 variable from memory. In some cases, however, a thunk can be elaborate. Perhaps Jensen’s device the most famous occurs in what is known as Jensen’s device, named after Jørn Jensen [Rut67]. The idea is to pass to a subroutine both a built-up expression and one or more of the variables used in the expression.
    [Show full text]
  • Design, Semantics and Implementation of the Ptolemy
    Computer Science Technical Reports Computer Science Summer 7-31-2015 Design, Semantics and Implementation of the Ptolemy Programming Language: A Language with Quantified yT ped Events Hridesh Rajan Iowa State University, [email protected] Gary T. Leavens University of Central Florida Follow this and additional works at: http://lib.dr.iastate.edu/cs_techreports Part of the Programming Languages and Compilers Commons Recommended Citation Rajan, Hridesh and Leavens, Gary T., "Design, Semantics and Implementation of the Ptolemy Programming Language: A Language with Quantified Typed Events" (2015). Computer Science Technical Reports. 376. http://lib.dr.iastate.edu/cs_techreports/376 This Article is brought to you for free and open access by the Computer Science at Iowa State University Digital Repository. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Design, Semantics and Implementation of the Ptolemy Programming Language: A Language with Quantified yT ped Events Abstract Implicit invocation (II) and aspect-oriented (AO) languages provide software designers with related but distinct mechanisms and strategies for decomposing programs into modules and composing modules into systems. II languages have explicitly announced events that run registered observer methods. AO languages have implicitly announced events that run method-like but more powerful advice. A limitation of II languages is their inability to refer to a large set of events succinctly. They also lack the expressive power of AO advice. Limitations of AO languages include potentially fragile dependence on syntactic structure that may hurt maintainability, and limits on the available set of implicit events and the reflective contextual information available.
    [Show full text]