Wyvern: a Simple, Typed, and Pure Object-Oriented Language

Total Page:16

File Type:pdf, Size:1020Kb

Wyvern: a Simple, Typed, and Pure Object-Oriented Language Wyvern: A Simple, Typed, and Pure Object-Oriented Language Ligia Nistor, Darya Kurilova, Stephanie Balzer, Benjamin Chung, Alex Potanin1, and Jonathan Aldrich Carnegie Mellon University flnistor, darya, balzers, bwchung, [email protected], [email protected] Abstract which are shared by more recent object-oriented languages, such The simplest and purest practical object-oriented language designs as Python, Ruby, Lua, and JavaScript: today are seen in dynamically-typed languages, such as Smalltalk • A high-level, pure object-oriented model, in which clients and Self. Static types, however, have potential benefits for produc- can interact with objects only by sending them messages. This tivity, security, and reasoning about programs. In this paper, we de- model of interaction enforces Meyer’s uniform access principle scribe the design of Wyvern, a statically typed, pure object-oriented [16], a principle stating that an object’s services should only be language that attempts to retain much of the simplicity and expres- available through a uniform notation (the object’s methods in siveness of these iconic designs. this case). Our goals lead us to combine pure object-oriented and func- tional abstractions in a simple, typed setting. We present a foun- • An interactive, value-based language model, which means that dational object-based language that we believe to be as close as everything significant in the language is a first-class value, one can get to simple typed lambda calculus while keeping object- either an object or a function. This contributes to a system that orientation. We show how this foundational language can be trans- is “directly manipulable” in the sense of Smith and Ungar [20]. lated to the typed lambda calculus via standard encodings. We then For example, classes in Smalltalk are not special declarations, define a simple extension to this language that introduces classes but live objects that respond to messages. and show that classes are no more than sugar for the foundational • A high degree of simplicity, with a few constructs sufficing to object-based language. Our future intention is to demonstrate that provide great expressiveness. modules and other object-oriented features can be added to our lan- guage as not more than such syntactical extensions while keeping • Good support for functional programming via blocks or the object-oriented core as pure as possible. lambda expressions and closures. The design of Wyvern closely follows both historical and mod- ern ideas about the essence of object-orientation, suggesting a new Interestingly, both Smalltalk and Self, as well as many lan- way to think about a minimal, practical, typed core language for guages that share some of the characteristics above, are dynam- objects. ically typed. Statically-typed object-oriented languages exist, but many are less pure (e.g., Java classes can expose fields), or less Categories and Subject Descriptors D.3.3 [Programming Lan- interactive (e.g., classes are typically not first-class), or may be guages]: Language Constructs and Features—Classes and objects; considerably more complex (C++ and Scala, despite their many D.3.1 [Programming Languages]: Formal Definitions and Theory virtues, come to mind). Static types are a potentially interesting addition to the set of General Terms Languages features above for a number of reasons. In object-oriented lan- guages, types can eliminate message-not-understood errors [12, 24] Keywords Object-oriented, first-class classes, static type check- and be used to optimize programs [10] and to create practical refac- ing toring tools [22]. Preliminary evidence suggests that, in some cir- cumstances, static types can enhance productivity as well [15]. 1. Introduction Our interest in this question comes from Wyvern, a language we The language designs of Smalltalk [11] and Self [20] are iconic are designing for secure mobile and web programming. To compare in their elegance, their simplicity, and the success with which they with programming languages in this domain, Wyvern must be a capture the essence of object-oriented programming. Although they simple, value-based, pure object-oriented language with good sup- are not among the most common languages used today, their de- port for functional programming—much like the languages men- sign has been an inspiration for many modern languages. Self and tioned above. However, we also want to provide strong reason- Smalltalk are notable for the following characteristics, many of ing about security properties. Reasoning is facilitated by a simple, high-level language, but, in addition, we want to use type-based ap- proaches to ensure certain security properties (e.g., using inference rules developed for type checking to also check object ownership and state). Thus, combining static types with a language having the Permission to make digital or hard copies of all or part of this work for personal or characteristics above is important to meeting this set of goals. classroom use is granted without fee provided that copies are not made or distributed This paper therefore explores the design of an object-oriented for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute language that is pure, value-based, simple, statically type-safe, and to lists, requires prior specific permission and/or a fee. supports functional programming. We explore variants with and MASPEGHI’13, July 01 2013, Montpellier, France without classes, our motivation being to show that, while classes are Copyright c 2013 ACM 978-1-4503-2046-7/13/07. $15.00 convenient, they are not fundamental to the object-oriented model. 1.1 What Makes an Object-Oriented Model Pure? 1 type Lot = Most of the criteria above are fairly clear. The exception involves 2 meth value : int the purity of the object model. What does it mean, especially in the 3 meth compare(other : Lot) : int context of types, for a language to be purely object-oriented? 4 meth sell : int To answer the question, we consider both history and theory. 5 With respect to history, Alan Kay, a pioneer of the object-oriented 6 meth purchase(q : int, p : int) : Lot = 7 new programming who developed Smalltalk, describes an “objects as 8 var qty : int = q server” metaphor in which each “object would be a server offer- 9 var price : int = p ing services” that clients can use by sending messages to the ob- 10 meth value : int = ject [13]. In fact, Kay writes that, in his opinion, “the big idea [of 11 this.qty * this.price 1 object-oriented programming] is messaging.” 12 meth compare(other : Lot) : int = With respect to theory, in his essay on the nature of objects, 13 this.value - other.value William Cook defines objects as “a value exporting a [sic] proce- 14 meth sell : int = dural interface to data or behavior” [9]. The notion of a procedural 15 val qtySold = this.qty 16 this.qty = 0 interface reflects Kay’s focus on messaging: the only way to inter- 17 qtySold act with an object is to invoke its methods. This is also consistent 18 with Meyer’s uniform access principle. 19 val aLot = purchase(100,100) Cook argues that a key benefit of objects, arising from their pro- 20 val d = aLot.compare(purchase(50,90)) cedural interface, is that different implementations of an interface 21 val value = aLot.value can interoperate. For example, in a pure object-oriented model, we 22 val qtySold = aLot.sell can take the union of a set implemented as a list with a set imple- mented as a hash table. Moreover, different implementations of an Figure 1. A Lot Object in the Object-Oriented Core of Wyvern interface can be treated uniformly: for example, we can store in- (Featherweight Wyvern) stances of two different implementations of a set within the same data structure. These benefits are used in many object-oriented sys- tems [5], and we consider them to be critical goals of our language as inheritance. We have not yet investigated adding inheritance or design. delegation to Wyvern. However, Wyvern does support specializa- These ideas can also be considered in a comparison between ob- tion and generalization of types, along with a pure object-oriented jects and module systems, particularly, with respect to encapsulat- model that supports reuse via composition mechanisms. Questions ing state. Concerning the development of object-oriented program- of interest to us as we continue the development of Wyvern are: ming, Kay writes of his motivations, “The large scale one was to • How far can a pure object-oriented model without inheritance find a better module scheme for complex systems involving hiding go in supporting code reuse? of details, and the small scale one was to find a more flexible ver- sion of assignment, and then to try to eliminate it altogether” [13]. • What reuse mechanisms would fit most naturally into a system Hiding assignment behind a method interface—via the uniform ac- with Wyvern’s design goals? cess principle—provides a more flexible version of assignment, and one can go further in using that method interface more abstractly to We are considering a reuse model for Wyvern based on delega- “replace bindings and assignment with goals” [13]. The procedural tion, possibly, with slightly simpler semantics compared to delega- interface of objects also makes them act like first-class modules.2 tion in Self [20]. From these sources, we extract three key requirements that we wish to satisfy in coming up with a typed, pure object-oriented 1.3 Contributions model: This paper makes the following contributions: • Uniform access principle. Following Meyer, Cook, and Kay, • Section 2 presents the design of a simple, typed, value-based, it should be possible to access objects only by invoking their pure object-oriented language.
Recommended publications
  • Application-Level Virtual Memory for Object-Oriented Systems Mariano Martinez Peck
    Application-Level Virtual Memory for Object-Oriented Systems Mariano Martinez Peck To cite this version: Mariano Martinez Peck. Application-Level Virtual Memory for Object-Oriented Systems. Program- ming Languages [cs.PL]. Université des Sciences et Technologie de Lille - Lille I, 2012. English. tel-00764991 HAL Id: tel-00764991 https://tel.archives-ouvertes.fr/tel-00764991 Submitted on 26 Dec 2012 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. N° d’ordre : 40886 THESE présentée en vue d’obtenir le grade de DOCTEUR en Spécialité : informatique par Mariano MARTINEZ PECK DOCTORAT DELIVRE CONJOINTEMENT PAR MINES DOUAI ET L’UNIVERSITE DE LILLE 1 Titre de la thèse : Application-Level Virtual Memory for Object-Oriented Systems Soutenue le 29/10/2012 à 10h devant le jury d’examen : Président Jean-Bernard STEFANI (Directeur de recherche – INRIA Grenoble- Rhône-Alpes) Directeur de thèse Stéphane DUCASSE (Directeur de recherche – INRIA Lille) Rapporteur Robert HIRSCHFELD (Professeur – Hasso-Plattner-Institut, Universität Potsdam, Allemagne) Rapporteur Christophe DONY (Professeur – Université Montpellier 2) Examinateur Roel WUYTS (Professeur – IMEC & Katholieke Universiteit Leuven, Belgique) co-Encadrant Noury BOURAQADI (Maître-Assistant – Mines de Douai) co-Encadrant Marcus DENKER (Chargé de recherche – INRIA Lille) co-Encadrant Luc FABRESSE (Maître-Assistant – Mines de Douai) Laboratoire(s) d’accueil : Dépt.
    [Show full text]
  • Visualage for Smalltalk Handbook Volume 2: Features
    SG24-2219-00 VisualAge for Smalltalk Handbook Volume 2: Features September 1997 SG24-2219-00 International Technical Support Organization VisualAge for Smalltalk Handbook Volume 2: Features September 1997 IBM Take Note! Before using this information and the product it supports, be sure to read the general information in Appendix A, “Special Notices.” First Edition (September 1997) This edition applies to VisualAge for Smalltalk, Versions 2, 3, and 4, for use with OS/2, AIX, and Microsoft Windows 95/NT. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. QXXE Building 80-E2 650 Harry Road San Jose, California 95120-6099 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation 1997. All rights reserved. Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp. Contents Preface . xiii How This Redbook Is Organized ....................... xiv ITSO on the Internet ................................ xv VisualAge Support on CompuServe ..................... xvii About the Authors ................................ xvii Acknowledgments . xviii Comments Welcome . xix Chapter 1. AS/400 Connection . 1 Multiple Programs with a Single Remote Procedure Call ......... 1 RPC Part Sets Commit Boundary ........................ 1 Connection Problem with V3R1 ......................... 2 AS/400 Communication Error .......................... 2 Strange Characters on Log-on Window .................... 3 Quick Form from AS/400 Record Classes ................... 3 Communication . 4 Read Next/Previous . 4 SQL Statements . 5 Data Queues and Records ............................ 6 ODBC Requirements .
    [Show full text]
  • Traits: Experience with a Language Feature
    7UDLWV([SHULHQFHZLWKD/DQJXDJH)HDWXUH (PHUVRQ50XUSK\+LOO $QGUHZ3%ODFN 7KH(YHUJUHHQ6WDWH&ROOHJH 2*,6FKRRORI6FLHQFH1(QJLQHHULQJ$ (YHUJUHHQ3DUNZD\1: 2UHJRQ+HDOWKDQG6FLHQFH8QLYHUVLW\ 2O\PSLD$:$ 1::DONHU5G PXUHPH#HYHUJUHHQHGX %HDYHUWRQ$25 EODFN#FVHRJLHGX ABSTRACT the desired semantics of that method changes, or if a bug is This paper reports our experiences using traits, collections of found, the programmer must track down and fix every copy. By pure methods designed to promote reuse and understandability reusing a method, behavior can be defined and maintained in in object-oriented programs. Traits had previously been used to one place. refactor the Smalltalk collection hierarchy, but only by the crea- tors of traits themselves. This experience report represents the In object-oriented programming, inheritance is the normal way first independent test of these language features. Murphy-Hill of reusing methods—classes inherit methods from other classes. implemented a substantial multi-class data structure called ropes Single inheritance is the most basic and most widespread type of that makes significant use of traits. We found that traits im- inheritance. It allows methods to be shared among classes in an proved understandability and reduced the number of methods elegant and efficient way, but does not always allow for maxi- that needed to be written by 46%. mum reuse. Consider a small example. In Squeak [7], a dialect of Smalltalk, Categories and Subject Descriptors the class &ROOHFWLRQ is the superclass of all the classes that $UUD\ +HDS D.2.3 [Programming Languages]: Coding Tools and Tech- implement collection data structures, including , , 6HW niques - object-oriented programming and . The property of being empty is common to many ob- jects—it simply requires that the object have a size method, and D.3.3 [Programming Languages]: Language Constructs and that the method returns zero.
    [Show full text]
  • Did Glooskap Kill the Dragon on the Kennebec? Roslyn
    DID GLOOSKAP KILL THE DRAGON ON THE KENNEBEC? ROSLYN STRONG Figure 1. Rubbing of the "dragon" petroglyph Figure 2. Rock in the Kennebec River, Embden, Maine The following is a revised version of a slide presentation I gave at a NEARA meeting a number of years ago. I have accumulated so many fascinating pieces of reference that the whole subject should really be in two parts, so I will focus here on the dragon legends and in a future article will dwell more on the mythology of the other petroglyphs, such as thunderbirds. This whole subject began for me at least eight years ago when George Carter wrote in his column "Before Columbus" in the Ellsworth American that only Celtic dragons had arrows on their tails. The dragon petroglyph [Fig. 1] is on a large rock [Fig. 2] projecting into the Kennebec river in the town of Embden, which is close to Solon, in central Maine. It is just downstream from the rapids, and before the water level was raised by dams, would have been a logical place to put in after a portage. The "dragon" is one of over a hundred petroglyphs which includes many diverse subjects - there are quite a few canoes, animals of various kinds, human and ‘thunderbird’ figures. They were obviously done over a long period of time since there are many layers and the early ones are fainter. They are all pecked or ‘dinted’ which is the term used by archaeologists. The styles and technique seem to be related to the petroglyphs at Peterborough, Ontario, which in turn appear to be similar to those in Bohuslan, Sweden.
    [Show full text]
  • Liste Von Programmiersprachen
    www.sf-ag.com Liste von Programmiersprachen A (1) A (21) AMOS BASIC (2) A# (22) AMPL (3) A+ (23) Angel Script (4) ABAP (24) ANSYS Parametric Design Language (5) Action (25) APL (6) Action Script (26) App Inventor (7) Action Oberon (27) Applied Type System (8) ACUCOBOL (28) Apple Script (9) Ada (29) Arden-Syntax (10) ADbasic (30) ARLA (11) Adenine (31) ASIC (12) Agilent VEE (32) Atlas Transformatikon Language (13) AIMMS (33) Autocoder (14) Aldor (34) Auto Hotkey (15) Alef (35) Autolt (16) Aleph (36) AutoLISP (17) ALGOL (ALGOL 60, ALGOL W, ALGOL 68) (37) Automatically Programmed Tools (APT) (18) Alice (38) Avenue (19) AML (39) awk (awk, gawk, mawk, nawk) (20) Amiga BASIC B (1) B (9) Bean Shell (2) B-0 (10) Befunge (3) BANCStar (11) Beta (Programmiersprache) (4) BASIC, siehe auch Liste der BASIC-Dialekte (12) BLISS (Programmiersprache) (5) Basic Calculator (13) Blitz Basic (6) Batch (14) Boo (7) Bash (15) Brainfuck, Branfuck2D (8) Basic Combined Programming Language (BCPL) Stichworte: Hochsprachenliste Letzte Änderung: 27.07.2016 / TS C:\Users\Goose\Downloads\Softwareentwicklung\Hochsprachenliste.doc Seite 1 von 7 www.sf-ag.com C (1) C (20) Cluster (2) C++ (21) Co-array Fortran (3) C-- (22) COBOL (4) C# (23) Cobra (5) C/AL (24) Coffee Script (6) Caml, siehe Objective CAML (25) COMAL (7) Ceylon (26) Cω (8) C for graphics (27) COMIT (9) Chef (28) Common Lisp (10) CHILL (29) Component Pascal (11) Chuck (Programmiersprache) (30) Comskee (12) CL (31) CONZEPT 16 (13) Clarion (32) CPL (14) Clean (33) CURL (15) Clipper (34) Curry (16) CLIPS (35)
    [Show full text]
  • Declarative Immutability in Java
    International Journal of Computer and Systems Engineering Volume 1 Issue 1 Article 4 July 2020 Declarative Immutability in Java John Crowley Boston College, University of Pennsylvania, [email protected] Follow this and additional works at: https://digitalcommons.fairfield.edu/ijcase Recommended Citation Crowley, John (2020) "Declarative Immutability in Java," International Journal of Computer and Systems Engineering: Vol. 1 : Iss. 1 , Article 4. Available at: https://digitalcommons.fairfield.edu/ijcase/vol1/iss1/4 This item has been accepted for inclusion in DigitalCommons@Fairfield by an authorized administrator of DigitalCommons@Fairfield. It is brought to you by DigitalCommons@Fairfield with permission from the rights- holder(s) and is protected by copyright and/or related rights. You are free to use this item in any way that is permitted by the copyright and related rights legislation that applies to your use. For other uses, you need to obtain permission from the rights-holder(s) directly, unless additional rights are indicated by a Creative Commons license in the record and/or on the work itself. For more information, please contact [email protected]. Declarative Immutability in Java Online at https://digitalcommons.fairfield.edu/ijcase/ Published by Fairfield University, DigitalCommons@Fairfield © 2020 Vol. 1, No. 1, 2020 Declarative Immutability in Java by John D. Crowley ABSTRACT A pervasive mechanism is proposed to declare that variables and object instances are mutable or immutable, and whether methods mutate instances. These declarations are integral to the type structure of the language and allow the developer to declare, and the reader (and compiler) to determine, if a variable or instance is immutable (even if other instances of the Class are mutable) or that an instance is immutable throughout the application (a Pure instance).
    [Show full text]
  • Gemstone/S Programming Guide
    GemStone® GemStone/S Programming Guide December 2001 GemStone/S Version 6.0 GemStone Programming Guide IMPORTANT NOTICE This manual and the information contained in it are furnished for informational use only and are subject to change without notice. GemStone Systems, Inc. assumes no responsibility or liability for any errors or inaccuracies that may appear in this manual or in the information contained in it. The manual, or any part of it, may not be reproduced, displayed, photocopied, transmitted or otherwise copied in any form or by any means now known or later developed, such as electronic, optical or mechanical means, without written authorization from GemStone Systems, Inc. Any unauthorized copying may be a violation of law. The software installed in accordance with this manual is copyrighted and licensed by GemStone Systems, Inc. under separate license agreement. This software may only be used pursuant to the terms and conditions of such license agreement. Any other use may be a violation of law. Limitations The software described in this manual is a customer-supported product. Due to the customer’s ability to change any part of a Smalltalk image, GemStone Systems, Inc. cannot guarantee that the GemStone programming environment will function with all Smalltalk images. 1988–2001 by GemStone Systems, Inc. All rights reserved. Use, duplication, or disclosure by the Government is subject to restrictions set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013. Trademarks GemStone, GemBuilder, GemConnect, GemEnterprise, andGemORB are registered trademark of GemStone Systems, Inc. The GemStone logo is a registered trademark of GemStone Systems, Inc.
    [Show full text]
  • A Metacircular Architecture for Runtime Optimisation Persistence Clément Béra
    Sista: a Metacircular Architecture for Runtime Optimisation Persistence Clément Béra To cite this version: Clément Béra. Sista: a Metacircular Architecture for Runtime Optimisation Persistence. Program- ming Languages [cs.PL]. Université de Lille 1, 2017. English. tel-01634137 HAL Id: tel-01634137 https://hal.inria.fr/tel-01634137 Submitted on 13 Nov 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Universit´edes Sciences et Technologies de Lille { Lille 1 D´epartement de formation doctorale en informatique Ecole´ doctorale SPI Lille UFR IEEA Sista: a Metacircular Architecture for Runtime Optimisation Persistence THESE` pr´esent´eeet soutenue publiquement le 15 Septembre 2017 pour l'obtention du Doctorat de l'Universit´edes Sciences et Technologies de Lille (sp´ecialit´einformatique) par Cl´ement B´era Composition du jury Pr´esident: Theo D'Hondt Rapporteur : Ga¨elThomas, Laurence Tratt Examinateur : Elisa Gonzalez Boix Directeur de th`ese: St´ephaneDucasse Co-Encadreur de th`ese: Marcus Denker Laboratoire d'Informatique Fondamentale de Lille | UMR USTL/CNRS 8022 INRIA Lille - Nord Europe Numero´ d’ordre: XXXXX i Acknowledgments I would like to thank my thesis supervisors Stéphane Ducasse and Marcus Denker for allowing me to do a Ph.D at the RMoD group, as well as helping and supporting me during the three years of my Ph.D.
    [Show full text]
  • The Future: the Story of Squeak, a Practical Smalltalk Written in Itself
    Back to the future: the story of Squeak, a practical Smalltalk written in itself Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay [Also published in OOPSLA ’97: Proc. of the 12th ACM SIGPLAN Conference on Object-oriented Programming, 1997, pp. 318-326.] VPRI Technical Report TR-1997-001 Viewpoints Research Institute, 1209 Grand Central Avenue, Glendale, CA 91201 t: (818) 332-3001 f: (818) 244-9761 Back to the Future The Story of Squeak, A Practical Smalltalk Written in Itself by Dan Ingalls Ted Kaehler John Maloney Scott Wallace Alan Kay at Apple Computer while doing this work, now at Walt Disney Imagineering 1401 Flower Street P.O. Box 25020 Glendale, CA 91221 [email protected] Abstract Squeak is an open, highly-portable Smalltalk implementation whose virtual machine is written entirely in Smalltalk, making it easy to debug, analyze, and change. To achieve practical performance, a translator produces an equivalent C program whose performance is comparable to commercial Smalltalks. Other noteworthy aspects of Squeak include: a compact object format that typically requires only a single word of overhead per object; a simple yet efficient incremental garbage collector for 32-bit direct pointers; efficient bulk- mutation of objects; extensions of BitBlt to handle color of any depth and anti-aliased image rotation and scaling; and real-time sound and music synthesis written entirely in Smalltalk. Overview Squeak is a modern implementation of Smalltalk-80 that is available for free via the Internet, at http://www.research.apple.com/research/proj/learning_concepts/squeak/ and other sites. It includes platform-independent support for color, sound, and image processing.
    [Show full text]
  • AIDA/Scribo a Powerful CMS at Your Fingertips!
    AIDA/Scribo a powerful CMS at your fingertips! Nicolas Petton Contents Why another CMS? Architecture History Scribo at work Future Demo Contents Why another CMS? Architecture History Scribo at work Future Demo What is a CMS? Content Management System Web application (Web CMS or WCMS) Used for creating and managing HTML content : HTML pages Associated documents (images, attached files, etc) Why another CMS? Leveraging Smalltalk strengths Leveraging Aida/Web strengths CMS framework for different CMS apps For developers and end users Leveraging AIDA/Web strengths RESTFull and nice looking URLs User, group, role support Security (Access control) Components Ajax integration Contents Why another CMS? Architecture History Scribo at work Future Demo Architecture Architecture Document Attachments Versioning Access rights Lifecycle Locking Workflow Multilingual Subdocuments support References Persistence Other Document Versioning Many versions Url always points to the released version Access to all versions (http://www.site.org/article.html? version=4) Document Lifecycle States during document's life : #pending, #released, #obsolete, ... Can be extended and tailored Document Workflow Managing flow of work through document lifecycle From editing, multiperson approvals, to releasing Who when what needs to do some task Email requesting for some task Email notifications of task done Document Subdocument Vertical hierarchy of documents Folder is a subclass of Document Folder can contain documents or other folders Document can have Chapters (again subclass
    [Show full text]
  • Scala for the Impatient Second Edition This Page Intentionally Left Blank Scala for the Impatient Second Edition
    Scala for the Impatient Second Edition This page intentionally left blank Scala for the Impatient Second Edition Cay S. Horstmann Boston • Columbus • Indianapolis • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City São Paulo • Sydney • Hong Kong • Seoul • Singapore • Taipei • Tokyo Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales department at [email protected] or (800) 382–3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the United States, please contact [email protected]. Visit us on the Web: informit.com/aw Library of Congress Control Number: 2016954825 Copyright © 2017 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise.
    [Show full text]
  • Towards Gradual Typing for Generics
    Towards Gradual Typing for Generics Lintaro Ina and Atsushi Igarashi Graduate School of Informatics, Kyoto University {ina,igarashi}@kuis.kyoto-u.ac.jp Abstract. Gradual typing, proposed by Siek and Taha, is a framework to combine the benefits of static and dynamic typing. Under gradual typing, some parts of the program are type-checked at compile time, and the other parts are type-checked at run time. The main advantage of gradual typing is that a programmer can write a program rapidly without static type annotations in the beginning of development, then add type annotations as the development progresses and end up with a fully statically typed program; and all these development steps are carried out in a single language. This paper reports work in progress on the introduction of gradual typing into class-based object-oriented programming languages with generics. In previous work, we have developed a gradual typing system for Feather- weight Java and proved that statically typed parts do not go wrong. After reviewing the previous work, we discuss issues raised when generics are introduced, and sketch a formalization of our solutions. 1 Introduction Siek and Taha have coined the term “gradual typing” [1] for a linguistic sup- port of the evolution from dynamically typed code, which is suitable for rapid prototyping, to fully statically typed code, which enjoys type safety properties, in a single programming language. The main technical challenge is to ensure some safety property even for partially typed programs, in which some part is statically typed and the rest is dynamically typed. The framework of gradual typing consists of two languages: the surface lan- guage in which programmers write programs and the intermediate language into which the surface language translates.
    [Show full text]