DOCSLIB.ORG

CSE 505: Concepts of Programming Languages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
CSE 505: Concepts of Programming Languages ' $ CSE 505: Concepts of Programming Languages Dan Grossman Fall 2005 Lecture 15 Object-Oriented Programming &Dan Grossman CSE505 Fall 2005, Lecture 15 1 % 'Don’t Believe the Hype $ OOP provides concise ways to build extensible software and exploit a sometimes-useful analogy between interaction of objects in physical systems and interaction of software parts. It also raises tricky semantic and style issues that require careful PL investigation. (Good thing we’re doing it near the end!) Personally, I am skeptical about: • The coding factor (X lines/day of accessor methods!) • The Barnes&Noble factor (certified insane in X days!) • The intro factor (by week X you can write your own class!) If it takes an advanced degree to understand objects, I’ve got the right audience! &Dan Grossman CSE505 Fall 2005, Lecture 15 2 % 'So what is OOP? $ It seems to look like this. That’s a lot; what’s the essence? class Point1 extends Object { int x; int get_x() { x } unit set_x(int y) { self.x = y } int distance(Point1 p) { p.get_x() - self.get_x() } constructor() { x = 0; } } class Point2 extends Point1 { int y; int get_y() { y } int get_x() { 34+super.get_x() } constructor() { super(); y=0; } } &Dan Grossman CSE505 Fall 2005, Lecture 15 3 % 'OOP can mean many things $ • An ADT (private fields) • Subtyping • Inheritance, method/field extension, method override • Implicit this/self • Dynamic dispatch • All the above (plus constructor(s)) with 1 class declaration Let’s consider how OO each of these is. Side question: Is “good design” many combinable constructs or one “do it all” construct? &Dan Grossman CSE505 Fall 2005, Lecture 15 4 % 'OO as ADT-focused $ Object/class members (fields, methods, constructors) often have visibilities and “more private” is sort of “more abstract” What code can invoke a method/access a field? Other methods in same object, other methods in same class, a subclass, within some other boundary (e.g., a package), any code, . With just classes, the only other way to hide a member is upcasting. With interfaces (which are more like record types), we can hide members more selectively: interface I { int distance(Point1 p); } class Point1 { ... I f() { self } ... } Previously we saw objects are a bad match for “strong binary methods” (we’ll come back to this) &Dan Grossman CSE505 Fall 2005, Lecture 15 5 % 'Records with private fields $ Let’s assume all fields are visible only to self object. Then objects are just a record of methods with private state. So far, this is no need for a fancy OO language: type t = { get_x : unit -> int; set_x : int -> unit; distance : t -> int } let point1_constructor () = let x = ref 0 in let rec self = { get_x = (fun () -> !x); set_x = (fun y -> x := y); distance = (fun p -> p.get_x() - self.get_x() ) } in self But there’s more to it (haven’t considered inheritance yet) &Dan Grossman CSE505 Fall 2005, Lecture 15 6 % 'Subtyping $ Most class-based OO languages “confuse” classes and types: • If C is a class, then C is a type. • If C extends D (via declaration), then C ≤ D. • Subtyping is (only) the reflexive, transitive closure of this. Is this novel? If C adds members, that’s width subtyping. This is “by name” subtyping. If classes C1 and C2 are incomparable in the class hierarchy they are incomparable types, even if they have the same members. We will definitely revisit this “subclassing is subtyping” assumption! (For now, it restricts subtyping and subclassing!) &Dan Grossman CSE505 Fall 2005, Lecture 15 7 % 'Subtyping, continued $ If C extends D and overrides a method of D, what restrictions should we have? • Argument types contravariant (assume less about arguments) • Result type covariant (provide more about result) Many “real” languages are even more restrictive. Some bend over backward to be more flexible. (Don’t!) It’s good we studied this in a simpler setting. &Dan Grossman CSE505 Fall 2005, Lecture 15 8 % 'Inheritance and Override $ A subclass inherits the fields and methods of its superclass. It can override some methods and have special “super” (a.k.a. resend) calls. This isn’t hard in ML either, (if the type system let you reuse field names): let point1_constructor () = let x = ref 0 in let rec self = { get_x = (fun () -> !x); set_x = (fun y -> x := y); distance = (fun p -> p.get_x() - self.get_x() ) } in self continued... &Dan Grossman CSE505 Fall 2005, Lecture 15 9 % 'Continued... $ let point2_constructor () = let r = point1_constructor () in let rec self = {get_x = (fun () -> 34 + r.get_x()); distance = r.distance; y = ref 0; ... } in self Also have to change point2 code when point1 changes, but often true in OO too (“fragile base class” issues). &Dan Grossman CSE505 Fall 2005, Lecture 15 10 % 'Then what is it? $ I claim class-based objects are poor (maybe okay) ADTs, same old subtyping, and a little syntactic sugar for extension and override. So what is that makes OO different in an intellectually interesting way? Answer: The “late” binding of self and the dynamic dispatch that results. The difference between point2_constructor() and an object of class Point2 is in the behavior of distance. &Dan Grossman CSE505 Fall 2005, Lecture 15 11 % 'More on late binding $ Late-binding, dynamic dispatch, and open recursion are all closely related ideas. The simplest example I know: Functional (even still O(n)) vs. OO (even now O(1)): let c1() = let rec r = { even i = if i > 0 then r.odd (i-1) else true; odd i = if i > 0 then r.even (i-1) else false} in r let c2() = let r1 = c1() in let rec r = {even = r1.even; odd i = i % 2 == 1} in r class C1 { int even(int i) {if i>0 then odd(i-1) else true} int odd(int i) {if i>0 then even(i-1) else false}} class C2 extends C1 { int odd(int i) {i % 2 == 1} } &Dan Grossman CSE505 Fall 2005, Lecture 15 12 % 'Political Spin $ “Call your congresspeople. Tell them C2 should have the right to change even by overriding odd. It’s a question of code reuse and you deserve better subclasses.” “Call your congresspeople. Tell them C1.even shouldn’t break whenever C2 decides to write a bad odd. You deserve quality code, regardless of subclasses.” Meanwhile, public television has a “boring” documentary about quiet behind-the-scenes work to understand the approaches and how the shortcomings of each can be compensated. &Dan Grossman CSE505 Fall 2005, Lecture 15 13 % 'Where We’re Going $ Now we know overriding and dynamic dispatch is the interesting part of the expression language. Now: • How exactly do we define method dispatch? • How do we use overriding for extensible software? • Revisiting “subtyping is subclassing” – Why contra/covariance is useful – Interfaces or object types for more subtyping – Subclassing not subtyping for more code reuse &Dan Grossman CSE505 Fall 2005, Lecture 15 14 % 'Defining Dispatch $ We want correct definitions, not super-efficient compilation techniques. Methods take “self” as an argument. (Compile down to functions taking an extra argument.) So just need self to refer to right thing. Approach 1: Each object has a “code pointer” for each method. For object returned by new C() where C extends D, use code pointers for D (inductive definition!) but: • If C overrides f replace code pointer for f • If C adds f, then add code pointer for f See homework 5. &Dan Grossman CSE505 Fall 2005, Lecture 15 15 % 'Dispatch continued $ Approach 2: Each object has a “type tag”. Object returned by new C() has tag C. Program state also has a “class table” mapping tags and method-names to code. For dispatch, look up (tag,name) in table. Approaches are equivalent, model dynamic dispatch correctly, and are routinely formalized in PL papers. First approach is “more eager” and consumes more space. Real implementations get best of both worlds with just a little more complication. Informal claim: This is hard to explain to freshmen, but in the presence of overriding, no simpler definition is correct. &Dan Grossman CSE505 Fall 2005, Lecture 15 16 % 'Overriding and Hierarchy Design $ Subclass writer decides what to override to modify behavior. (Style: Modification should be specialization, but language doesn’t check that.) Superclass writer often has ideas on what will be overridden. Leads to abstract methods (must override) and abstract classes: • An abstract class has > 0 abstract methods • Overriding an abstract method makes it non-abstract • Cannot call constructor of an abstract class Adds no expressiveness (superclass could implement method to raise an exception), but uses static checking to enforce an idiom and saves you a handful of keystrokes. &Dan Grossman CSE505 Fall 2005, Lecture 15 17 % 'Overriding for Extensibility $ A PL example: class Exp { abstract Value eval(Env); abstract Typ typecheck(Ctxt); } class IntExp extends class Exp { Int i; Value eval(Env e) { new IntValue(self.i) } Typ typecheck(Ctxt c) { new IntTyp() } } &Dan Grossman CSE505 Fall 2005, Lecture 15 18 % 'Example Continued $ class AddExp extends class Exp { Exp e1; Exp e2; Value eval(Env e) { new IntValue(e1.eval(e).toInt().add( e2.eval(e).toInt())); } Typ typecheck(Ctxt c) { if(e1.typecheck(c).equals(new IntTyp()) && e2.typecheck(c).equals(new IntTyp())) new IntTyp() else raise new TypeError() } } toInt may raise an exception (Value definition not shown) “Impure” OO may have a plus primitive (not a method call) &Dan Grossman CSE505 Fall 2005, Lecture 15 19 % 'Extending the example $ If we add a new variant of expression (e.g., MultExp) we need not change any existing code. In ML-style, we do. If we add a new operation (e.g., toString) we need to change Exp and all subclasses. In ML, no change to existing code. If we add a new type of value (e.g., Bool): • ML patterns need new case but _ may avoid it • Value subclasses need new method (e.g., toBool) but concrete method in superclass (to raise an exception) may localize the change.
Load more

Recommended publications
  • Programming Languages & Paradigms Abstraction & Modularity
    Programming Languages & Paradigms PROP HT 2011 Abstraction & Modularity Lecture 6 Inheritance vs. delegation, method vs. message Beatrice Åkerblom [email protected] 2 Thursday, November 17, 11 Thursday, November 17, 11 Modularity Modularity, cont’d. • Modular Decomposability • Modular Understandability – helps in decomposing software problems into a small number of less – if it helps produce software in which a human reader can understand complex subproblems that are each module without having to know the others, or (at worst) by •connected by a simple structure examining only a few others •independent enough to let work proceed separately on each item • Modular Continuity • Modular Composability – a small change in the problem specification will trigger a change of – favours the production of software elements which may be freely just one module, or a small number of modules combined with each other to produce new systems, possibly in a new environment 3 4 Thursday, November 17, 11 Thursday, November 17, 11 Modularity, cont’d. Classes aren’t Enough • Modular Protection • Classes provide a good modular decomposition technique. – the effect of an error at run-time in a module will remain confined – They possess many of the qualities expected of reusable software to that module, or at worst will only propagate to a few neighbouring components: modules •they are homogenous, coherent modules •their interface may be clearly separated from their implementation according to information hiding •they may be precisely specified • But more is needed to fully achieve the goals of reusability and extendibility 5 6 Thursday, November 17, 11 Thursday, November 17, 11 Polymorphism Static Binding • Lets us wait with binding until runtime to achieve flexibility • Function call in C: – Binding is not type checking – Bound at compile-time – Allocate stack space • Parametric polymorphism – Push return address – Generics – Jump to function • Subtype polymorphism – E.g.
    [Show full text]
  • Concepts of Object-Oriented Programming AS 2019
    Concepts of Object-Oriented Programming AS 2019 Exercise 6 Multiple Inheritance, Multiple Dispatch and Linearization November 1, 2019 Task 1 (from a previous exam) Consider the following C++ program: class X{ public: X(int p) : fx(p) {} int fx; }; class Y{ public: Y(int p) : fy(p) {} int fy; }; class B: public virtual X,public Y{ public: B(int p) : X(p-1),Y(p-2){} }; class C: public virtual X,public Y{ public: C(int p) : X(p+1),Y(p+1){} }; class D: public B, public C{ public: D(int p) : X(p-1), B(p-2), C(p+1){} }; int main() { D* d = new D(5); B* b = d; C* c = d; std::cout << b->fx << b->fy << c->fx << c->fy; return 0; } What is the output of running the program? (a) 5555 (b) 2177 (c) CORRECT: 4147 (d) 7177 (e) 7777 (f) None of the above Task 2 (from a previous exam) Consider the following Java classes: class A{ public void foo (Object o) { System.out.println("A"); } } class B{ public void foo (String o) { System.out.println("B"); } } class C extends A{ public void foo (String s) { System.out.println("C"); } } class D extends B{ public void foo (Object o) { System.out.println("D"); } } class Main { public static void main(String[] args) { A a = new C(); a.foo("Java"); C c = new C(); c.foo("Java"); B b = new D(); b.foo("Java"); D d = new D(); d.foo("Java"); } } What is the output of the execution of the method main in class Main? (a) The code will print A C B D (b) CORRECT: The code will print A C B B (c) The code will print C C B B (d) The code will print C C B D (e) None of the above Task 3 Consider the following C# classes: public class
    [Show full text]
  • Safely Creating Correct Subclasses Without Superclass Code Clyde Dwain Ruby Iowa State University
    Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 2006 Modular subclass verification: safely creating correct subclasses without superclass code Clyde Dwain Ruby Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons Recommended Citation Ruby, Clyde Dwain, "Modular subclass verification: safely creating correct subclasses without superclass code " (2006). Retrospective Theses and Dissertations. 1877. https://lib.dr.iastate.edu/rtd/1877 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Modular subclass verification: Safely creating correct subclasses without superclass code by Clyde Dwain Ruby A dissertation submitted to the graduate faculty in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Major: Computer Science Program of Study Committee Gary T. Leavens, Major Professor Samik Basu Clifford Bergman Shashi K. Gadia Jonathan D. H. Smith Iowa State University Ames, Iowa 2006 Copyright © Clyde Dwain Ruby, 2006. All rights reserved. UMI Number: 3243833 Copyright 2006 by Ruby, Clyde Dwain All rights reserved. UMI Microform 3243833 Copyright 2007 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.O. Box 1346 Ann Arbor, MI 48106-1346 ii TABLE OF CONTENTS ACKNOWLEDGEMENTS .
    [Show full text]
  • Safely Creating Correct Subclasses Without Seeing Superclass Code
    Safely Creating Correct Subclasses without Seeing Superclass Code Clyde Ruby and Gary T. Leavens TR #00-05d April 2000, revised April, June, July 2000 Keywords: Downcalls, subclass, semantic fragile subclassing problem, subclassing contract, specification inheritance, method refinement, Java language, JML language. 1999 CR Categories: D.2.1 [Software Engineering] Requirements/Specifications — languages, tools, JML; D.2.2 [Software Engineering] Design Tools and Techniques — Object-oriented design methods, software libraries; D.2.3 [Software Engineering] Coding Tools and Techniques — Object-oriented programming; D.2.4 [Software Engineering] Software/Program Verification — Class invariants, correctness proofs, formal methods, programming by contract, reliability, tools, JML; D.2.7 [Software Engineering] Distribution, Maintenance, and Enhancement — Documentation, Restructuring, reverse engineering, and reengi- neering; D.2.13 [Software Engineering] Reusable Software — Reusable libraries; D.3.2 [Programming Languages] Language Classifications — Object-oriented langauges; D.3.3 [Programming Languages] Language Constructs and Features — classes and objects, frameworks, inheritance; F.3.1 [Logics and Meanings of Programs] Specifying and Verifying and Reasoning about Programs — Assertions, invariants, logics of programs, pre- and post-conditions, specification techniques; To appear in OOPSLA 2000, Minneapolis, Minnesota, October 2000. Copyright c 2000 ACM. Permission to make digital or hard copies of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Department of Computer Science 226 Atanasoff Hall Iowa State University Ames, Iowa 50011-1040, USA Safely Creating Correct Subclasses without Seeing Superclass Code ∗ Clyde Ruby and Gary T.
    [Show full text]
  • Programming-In-Scala.Pdf
    Cover · Overview · Contents · Discuss · Suggest · Glossary · Index Programming in Scala Cover · Overview · Contents · Discuss · Suggest · Glossary · Index Programming in Scala Martin Odersky, Lex Spoon, Bill Venners artima ARTIMA PRESS MOUNTAIN VIEW,CALIFORNIA Cover · Overview · Contents · Discuss · Suggest · Glossary · Index iv Programming in Scala First Edition, Version 6 Martin Odersky is the creator of the Scala language and a professor at EPFL in Lausanne, Switzerland. Lex Spoon worked on Scala for two years as a post-doc with Martin Odersky. Bill Venners is president of Artima, Inc. Artima Press is an imprint of Artima, Inc. P.O. Box 390122, Mountain View, California 94039 Copyright © 2007, 2008 Martin Odersky, Lex Spoon, and Bill Venners. All rights reserved. First edition published as PrePrint™ eBook 2007 First edition published 2008 Produced in the United States of America 12 11 10 09 08 5 6 7 8 9 ISBN-10: 0-9815316-1-X ISBN-13: 978-0-9815316-1-8 No part of this publication may be reproduced, modified, distributed, stored in a retrieval system, republished, displayed, or performed, for commercial or noncommercial purposes or for compensation of any kind without prior written permission from Artima, Inc. All information and materials in this book are provided "as is" and without warranty of any kind. The term “Artima” and the Artima logo are trademarks or registered trademarks of Artima, Inc. All other company and/or product names may be trademarks or registered trademarks of their owners. Cover · Overview · Contents · Discuss · Suggest · Glossary · Index to Nastaran - M.O. to Fay - L.S. to Siew - B.V.
    [Show full text]
  • Selective Open Recursion: a Solution to the Fragile Base Class Problem
    Selective Open Recursion: A Solution to the Fragile Base Class Problem Jonathan Aldrich School of Computer Science Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213, USA [email protected] ABSTRACT public class CountingSet extends Set { private int count; Current object-oriented languages do not fully protect the implementation details of a class from its subclasses, mak- public void add(Object o) { ing it difficult to evolve that implementation without break- super.add(o); ing subclass code. Previous solutions to the so-called fragile count++; base class problem specify those implementation dependen- } cies, but do not hide implementation details in a way that al- public void addAll(Collection c) { lows effective software evolution. super.addAll(c); In this paper, we show that the fragile base class problem count += c.size(); arises because current object-oriented languages dispatch } methods using open recursion semantics even when these se- public int size() { mantics are not needed or wanted. Our solution is to make return count; explicit the methods to which open recursion should apply. } We propose to change the semantics of object-oriented dis- } patch, such that all calls to “open” methods are dispatched dynamically as usual, but calls to “non-open” methods are dispatched statically if called on the current object this, but Figure 1: The correctness of the CountingSet class de- dynamically if called on any other object. By specifying a pends on the independence of add and addAll in the im- method as open, a developer is promising that future ver- plementation of Set. If the implementation is changed sions of the class will make internal calls to that method in so that addAll uses add, then count will be incremented exactly the same way as the current implementation.
    [Show full text]
  • Why Objects Are Inevitable
    The Power of Interoperability: Why Objects Are Inevitable Onward! Essay, 2013 http://www.cs.cmu.edu/~aldrich/papers/objects-essay.pdf Comments on this work are welcome. Please send them to aldrich at cmu dot edu Jonathan Aldrich Institute for Software Research School of Computer Science Carnegie Mellon University Copyright © 2013 by Jonathan Aldrich. This work is made available under the terms of the Creative Commons Attribution-ShareAlike 3.0 license: http://creativecommons.org/licenses/by-sa/3.0/ Object-Oriented Programming is Widespread 6-8 of top 10 PLs are OO – TIOBE 3 Object-Oriented Programming is Influential • Major conferences: OOPSLA, ECOOP • Turing awards for Dahl and Nygaard, and Kay • Other measures of popularity • Langpop.com: 6-8 of most popular languages • SourceForge: Java, C++ most popular • GitHub: JavaScript, Ruby most popular • Significant use of OO design even in procedural languages • Examples: GTK+, Linux kernel, etc. • Why this success? 4 OOP Has Been Criticized “I find OOP technically unsound… philosophically unsound… [and] methodologically wrong. ” - Alexander Stepanov, developer of the C++ STL 5 Why has OOP been successful? 6 Why has OOP been successful? “…it was hyped [and] it created a new software industry.” - Joe Armstrong, designer of Erlang Marketing/adoption played a role in the ascent of OOP. But were there also genuine advantages of OOP? 7 Why has OOP been successful? “the object-oriented paradigm...is consistent with the natural way of human thinking” - [Schwill, 1994] OOP may have psychological benefits. But is there a technical characteristic of OOP that is critical for modern software? 8 What kind of technical characteristic? Talk Outline 1.
    [Show full text]
  • Fragile Base-Class Problem, Problem?
    Noname manuscript No. (will be inserted by the editor) Fragile Base-class Problem, Problem? Aminata Saban´e · Yann-Ga¨elGu´eh´eneuc · Venera Arnaoudova · Giuliano Antoniol Received: date / Accepted: date Abstract The fragile base-class problem (FBCP) has likely to change nor more likely to have faults. Qualita- been described in the literature as a consequence of tively, we conduct a survey to confirm/infirm that some \misusing" inheritance and composition in object-orien- bugs are related to the FBCP. The survey involves 41 ted programming when (re)using frameworks. Many re- participants that analyse a total of 104 bugs of three search works have focused on preventing the FBCP by open-source systems. Results indicate that none of the proposing alternative mechanisms for reuse, but, to the analysed bugs is related to the FBCP. best of our knowledge, there is no previous research Thus, despite large, rigorous quantitative and quali- work studying the prevalence and impact of the FBCP tative studies, we must conclude that the two aspects of in real-world software systems. The goal of our work is the FBCP that we analyse may not be as problematic thus twofold: (1) assess, in different systems, the preva- in terms of change and fault-proneness as previously lence of micro-architectures, called FBCS, that could thought in the literature. We propose reasons why the lead to two aspects of the FBCP, (2) investigate the re- FBCP may not be so prevalent in the analysed systems lation between the detected occurrences and the quality and in other systems in general.
    [Show full text]
  • =5Cm Cunibig Concepts in Programming Languages
    Concepts in Programming Languages Alan Mycroft1 Computer Laboratory University of Cambridge 2016–2017 (Easter Term) www.cl.cam.ac.uk/teaching/1617/ConceptsPL/ 1Acknowledgement: various slides are based on Marcelo Fiore’s 2013/14 course. Alan Mycroft Concepts in Programming Languages 1 / 237 Practicalities I Course web page: www.cl.cam.ac.uk/teaching/1617/ConceptsPL/ with lecture slides, exercise sheet and reading material. These slides play two roles – both “lecture notes" and “presentation material”; not every slide will be lectured in detail. I There are various code examples (particularly for JavaScript and Java applets) on the ‘materials’ tab of the course web page. I One exam question. I The syllabus and course has changed somewhat from that of 2015/16. I would be grateful for comments on any remaining ‘rough edges’, and for views on material which is either over- or under-represented. Alan Mycroft Concepts in Programming Languages 2 / 237 Main books I J. C. Mitchell. Concepts in programming languages. Cambridge University Press, 2003. I T.W. Pratt and M. V.Zelkowitz. Programming Languages: Design and implementation (3RD EDITION). Prentice Hall, 1999. ? M. L. Scott. Programming language pragmatics (4TH EDITION). Elsevier, 2016. I R. Harper. Practical Foundations for Programming Languages. Cambridge University Press, 2013. Alan Mycroft Concepts in Programming Languages 3 / 237 Context: so many programming languages Peter J. Landin: “The Next 700 Programming Languages”, CACM (published in 1966!). Some programming-language ‘family trees’ (too big for slide): http://www.oreilly.com/go/languageposter http://www.levenez.com/lang/ http://rigaux.org/language-study/diagram.html http://www.rackspace.com/blog/ infographic-evolution-of-computer-languages/ Plan of this course: pick out interesting programming-language concepts and major evolutionary trends.
    [Show full text]
  • A Reflective Component-Oriented Programming Language
    ! ! !"#$%&'(&)'*+,-"+"&.(.$/&'/0'('1"0-"2.$3"'4/+,/&"&.567$"&.")' 87/%7(++$&%'(&)'9/)"-$&%':(&%;(%"' <=' 8".7'>8?4@A' ACADÉMIE DE MONTPELLIER U NIVERSITÉ M ONTPELLIER II — SCIENCES ET TECHNIQUES DU LANGUEDOC — THÈSE présentée au Laboratoire d’Informatique de Robotique et de Microélectronique de Montpellier pour obtenir le diplôme de doctorat SPÉCIALITÉ : INFORMATIQUE Formation Doctorale : Informatique École Doctorale : Information, Structures, Systèmes Design and Implementation of a Reflective Component-Oriented Programming and Modeling Language par Petr SPACEK Soutenue le 17 decembre 2013 at ??h, devant le jury composé de : Lionel SEINTURIER, Professeur, Inria, University Lille 1, France . Rapporteur Ivica CRNKOVIC, Professeur, IDT, Mälardalen University, Sweden, . Rapporteur Pierre COINTE, Professeur, LINA, Université de Nantes, France . Examinateur Roland DUCOURNAU, Professeur, LIRMM, Université Montpellier II, France . Président Christophe DONY, Professeur, LIRMM, Université Montpellier II, France . Directeur de Thèse Chouki TIBERMACINE, Associer Professeur, LIRMM, Université Montpellier II, France . Co-Directeur de Thèse Version of October 27, 2013 Contents Contents iii Acknowledgement vii Abstract ix Résumé xi 1 Introduction 1 1.1 Context: Component-based Software Engineering ...................... 2 1.2 Limitations of the Existing Approaches ............................. 4 1.3 SCL, the predecessor of our work ................................ 7 1.4 The problematic of the thesis .................................. 8 1.5 Characteristics
    [Show full text]
  • Inheritance (Chapter 7)
    Inheritance (Chapter 7) Prof. Dr. Wolfgang Pree Department of Computer Science University of Salzburg cs.uni-salzburg.at Inheritance – the soup of the day? ! Inheritance combines three aspects: inheritance of implementation, inheritance of interfaces, and establishment of substitutability (substitutability is not required – although recommended). ! Inheritance: " subclassing – that is, inheritance of implementation fragments/code usually called implementation inheritance; " subtyping – that is, inheritance of contract fragments/interfaces, usually called interface inheritance; and " Promise of substituatability. 2 W. Pree Multiple inheritance (1) ! In principle, there is no reason for a class to have only one superclass. ! Two principal reasons for supporting multiple inheritance " to allow interfaces from different sources to be merged, aiming for simultaneous substitutability with objects defined in mutually unaware contexts. " to merge implementations from different sources. ! Multiple interface inheritance does not introduce any major technical problems beyond those already introduced by single interface inheritance. 3 W. Pree Multiple inheritance (2) ! Approaches to the semantics of multiple inheritance usually stay close to the implementation strategy chosen. ! Java supports multiple interface inheritance but is limited to single implementation inheritance. The diamond inheritance problem is thus elegantly solved by avoidance without giving up on the possibility of inheriting multiple interfaces. 4 W. Pree Mixins ! Multiple inheritance can be used in a particular style called mixin inheritance. A class inherits interfaces from one superclass and implementations from several superclasses, each focusing on distinct parts of the inherited interface. 5 W. Pree Mixins (2) 6 W. Pree The fragile base class problem ! The question is whether or not a class can evolve – appear in new releases without breaking independently developed subclasses.
    [Show full text]
  • Objects As Session-Typed Processes
    Objects as Session-Typed Processes Stephanie Balzer and Frank Pfenning Computer Science Department Carnegie Mellon University Abstract an extensive survey of the object-oriented literature, Arm- A key idea in object-oriented programming is that objects strong [8] identifies 39 concepts generally associated with encapsulate state and interact with each other by message object-oriented programming, such as object, encapsulation, exchange. This perspective suggests a model of computation inheritance, message passing, information hiding, dynamic that is inherently concurrent (to facilitate simultaneous mes- dispatch, reuse, modularization, etc., out of which she dis- sage exchange) and that accounts for the effect of message tills the “quarks” of object-orientation, which are: object and exchange on an object’s state (to express valid sequences of class, encapsulation and abstraction, method and message state transitions). In this paper we show that such a model passing, dynamic dispatch and inheritance. of computation arises naturally from session-based commu- These findings are consistent with the concepts sup- nication. We introduce an object-oriented programming lan- ported by the protagonists of object-oriented languages: guage that has processes as its only objects and employs lin- Simula [19, 20] introduced the notions of an object and ear session types to express the protocols of message ex- a class and substantiated the idea to encapsulate the op- change and to reason about concurrency and state. Based on erations and the data on which they operate in an object. various examples we show that our language supports the Smalltalk [30] put forward the message-passing aspect of typical patterns of object-oriented programming (e.g., en- object-orientation by viewing computation as message ex- capsulation, dynamic dispatch, and subtyping) while guar- change, whereby messages are dispatched dynamically ac- anteeing session fidelity in a concurrent setting.
    [Show full text]