ArticlePDF Available

A Shared View of Sharing: The Treaty of Orlando

Authors:

Abstract

Introduction For the past few years, researchers have been debating the relative merits of object-oriented languages with classes and inheritance as opposed to those with prototypes and delegation. It has become clear that the object-oriented programming language design space is not a dichotomy. Instead, we have identified two fundamental mechanisms---templates and empathy---and several different independent degrees of freedom for each. Templates create new objects in their own image, providing guarantees about the similarity of group members. Empathy allows an object to act as if it were some other object, thus providing sharing of state and behavior. The Smalltalk-80 TM language, 1 Actors, Lieberman's Delegation system, Self, and Hybrid each take differing stands on the forms of templates 1 Smalltalk-80 TM is a trademark of Par
... Programming language support for roles can be traced back all the way to SELF (Ungar & Smith 1987) which demonstrated the universal applicability of object-based inheritance paving the road for the Treaty of Orlando (Stein, Lieberman, & Ungar 1989). ...
... (Kappel, Retschitzegger, & Schwinger 1998) identify significant differences among proposed role languages regarding method dispatch.3 See(Stein, Lieberman, & Ungar 1989) and our discussion of related work. 4 See, e.g.,(Steimann 2000). ...
... Class-based programming, the most popular one having in SmallTalk, C++ and Java its main languages. And Prototype-based programming, a way of programming without classes, and sometimes also named Object-based, because only objects exists in this approach Prototypes were popularized at ECOOP '86 as an alternative object-oriented paradigm, when Henry Lieberman [Lie86] presented a different way of sharing behavior between objects, that later on motivates The Treaty of Orlando [SLU89], a Treaty two compare advantages and disadvantages between the way that classbased object and prototype-based object share behavior and properties. However, the basic concepts come from a long history of a philosophical discussion about the representation of abstractions. ...
Article
Agents succeeded as mobile entities that properly solved problems on mobile systems. They can move around the network in a transparent way, and communicate with other agents by sending messages. But the relationship between agents does not have a strong structure, and big multi agent systems become hard to maintain and to understand. The primary aim of this work is to provide a way to organize agents in mobile systems. Objects help us to have a structured way of programming, but if we want objects moving around different address spaces, we need them to be self-supporting. When objects depends on a class, we also need to move the class everywhere the object goes, and to have a sophisticated system for type checking. We decided to use Prototype-Based Programming, a paradigm to program without classes, which has a proper way of reasoning about sharing, an important property for our purpose to organize the system. We extend Borg, a language to implement autonomous agents in a wide area network. The extension provides methods to create prototypes that can move and be extended through the network. The objects and their extensions use distributed delegation to share behavior and state, having a clear hierarchy and structure, helping us to maintain and evolve the systems.
... Le mod ele a classes est complexe Borning, 1986;LaLonde et al., 1986;Lalonde, 1989;Stein et al., 1989], parce que les classes y jouent dii erents r^ oles qu'il est parfois diicile de dissocier et qui peuvent rendre leur conception, leur mise en uvre et leur maintenance diicile. Notons parmi ces r^ oles : descripteur de la structure des instances, biblioth eque de comportements pour les instances, support de l'encapsulation et support a l'implantation de types abstraits, a l'organisation des programmes, a la modularit e, au partage entre descriptions de concepts, a la r eutilisation. ...
Chapter
R esum e Les langages a prototypes proposent une forme de programmation par objets s'appuyant sur la repr esentation d'objets concrets plut^ ot que sur celle de concepts, ou plus pragmatiquement, une forme de programmation par objets sans classes. Ce chapitre d ecrit ces langages, les raisons qui ont conduit a leur emergence, les possibilit es nouvelles qu'ils apportent, mais aussi les pro-bl emes qu'ils posent. Nous r epondons en premier lieu aux questions suivantes. Qu'est-ce qu'un prototype? Qu'est-ce qu'un objet concret? Pourquoi chercher a se passer des classes? Quelle est l'architecture primitive d'un langage a prototypes et quelle est la gen ese de ces langages? Nous caract erisons plus pr ecis ement les deux m ecanismes de cr eation d'objets : le clonage, et la description dii erentielle. Cette caract erisation nous permet de dii erencier l'h eritage dans les hi erarchies d'objets (la d el egation) de l'h eritage via des hi erarchies de classes (qui est l'h eritage classique des langages a objets). Elle nous permet egalement de pr esenter les sp eciicit es ainsi que les probl emes que pose la programmation par prototypes. Au travers de cette pr esentation critique, nous posons nalement la question de l'int er^ et et de l'avenir de cette forme de programmation par objets.
Article
This paper's primary aim is to improve the understanding of the delegation mechanism as defined in [18]. We propose a new characterization of delegation based on the notions of name sharing, property sharing and value sharing. It allows us (1) to clearly differentiate delegation from class-inheritance in particular and more generally from other inheritance mechanisms and (2) to explain how a founded use of delegation relies on a correct semantics of variable property sharing between objects connected by a delegation link. We then describe a model of split objects which is proposed as an example of a disciplined and semantically founded use of delegation, where property sharing expresses viewpoints within objects.
Article
Full-text available
R esum e: Le but de cet article est d'am eliorer la compr ehension du m ecanisme de d el egation tel qu'il est d eeni dans Nous proposons une nouvelle caract eri-sation de la d el egation bas ee sur les notions de partage de noms, partage de propri et es et partage de valeurs. Cela nous permet 1 de dii erencier clairement l a d e-l egation et l'h eritage de classes et 2 d'expliquer com-ment une utilisation fond ee de la d el egation repose sur une s emantique correcte pour le partage de variables entre objets connect es par un lien de d el egation. Nous d ecrivons ensuite un mod ele d'objets morcel es qui est propos e comme un exemple d'utilisation disciplin ee et s emantiquement fond ee de la d el egation, dans laquelle le partage de propri et es exprime des points de vues au sein d'un objet.
Article
This paper's primary aim is to improve the understanding of the delegation mechanism as defined in [18]. We propose a new characterization of delegation based on the notions of name sharing, property sharing and value sharing. It allows us (1) to clearly differentiate delegation from class-inheritance in particular and more generally from other inheritance mechanisms and (2) to explain how a founded use of delegation relies on a correct semantics of variable property sharing between objects connected by a delegation link. We then describe a model of split objects which is proposed as an example of a disciplined and semantically founded use of delegation, where property sharing expresses viewpoints within objects.
Article
Full-text available
To effectively model complex applications in which constantly changing situations can be represented, a database system must be able to support the runtime specification of structural and behavioral nuances for objects on an individual or group basis. This paper introduces the role mechanism as an extension of object-oriented databases to support unanticipated behavioral oscillations for objects that may attain many types and share a single object identity. A role refers to the ability to represent object dynamics by seamlessly integrating idiosyncratic behavior, possibly in response to external events, with pre-existing object behavior specified at instance creation time. In this manner, the same object can simultaneously be an instance of different classes which symbolize the different roles that this object assumes. The role concept and its underlying linguistic scheme simplify the design requirements of complex applications that need to create and manipulate dynamic objects.
Article
Full-text available
Confronto tre meccanismi di condivisione: ereditarietà, delega e concatenazione. Definisco sintassi, semantica e tipi di tre nuclei di linguaggio scelti in modo da differire solo per il meccanismo di condivisione. Dimostro l'equivalenza dei tre linguaggi e quindi dei tre meccanismi. Introduzione L'ereditarietà è il meccanismo di condivisione più diffuso ed è spesso indicata come la proprietà distintiva che differenzia la programmazione orientata agli oggetti da altri paradigmi. Il termine ereditarietà è spesso usato come sinonimo di meccanismo di condivisione. Sono stati fatti alcuni tentativi di definire una tassonomia per i meccanismi di condivisione esistenti. L'intento dichiarato in questi scritti è stato di classificare tutte le possibili varianti; nessun tentativo è stato fatto per isolare i meccanismi da proprietà accidentali non esclusive e confrontarli con metodi formali in modo da individuare le reali differenze. Inoltre, in letteratura è rappresentata prevalentemente la contrapposizione fra meccanismi basati su classi e meccanismi basati su oggetti; questi ultimi identificati con il meccanismo di delega. Solo di recente è stata compresa l'originalità e la rilevanza della concatenazione. Le idee alla base della programmazione class-based e object-based si possono fare risalire agli inizi degli anni sessanta; diciamo rispettivamente con Simula nel 1967 e Sketchpad nel 1963. I linguaggi object-based vengono usati in studi fondazionali e programmazione esplorativa ma anche in alcuni ambiti accessibili ad un pubblico più vasto come i palmari (NewtonScript) e i browser (JavaScript). I sostenitori della programmazione basata su oggetti attribuiscono al proprio modello maggiore concretezza, semplicità concettuale e flessibilità. Non di meno il paradigma dominante è quello basato su classi e ad oltre trent'anni di distanza nessun linguaggio object-based può essere considerato un serio antagonista di linguaggi come C++ o Java. Sono state avanzate diverse ipotesi per spiegare le ragioni di questo insuccesso. Gran parte dei meriti e dei limiti descritti in letteratura e attribuiti all'uno o all'altro modello sono in realtà da attribuire a proprietà indipendenti e applicabili ad entrambi i modelli e che solo per ragioni storiche si trovano prevalentemente adottate nell'uno o nell'altro. Proprietà come le operazioni sugli attributi, l'uniformità di trattamento degli attributi e l'ereditarietà dinamica sono presenti nella maggior parte dei linguaggi object-based ma non in quelli class-based. Queste proprietà sono una naturale estensione dei linguaggi basati su oggetti ma non sono intrinsecamente legate ad essi come dimostrano alcuni linguaggi basati su classi (Hybrid). Ogni meccanismo di condivisione definisce un modello concettuale con una propria terminologia ed una propria metafora di riferimento. Altre differenze sono osservabili nel modello di implementazione e nella rappresentazione; ancora una volta è importante chiedersi quali differenze siano inerenti ai modelli e quali invece siano motivate solo da ragioni storiche e possano essere superate. Un meccanismo di condivisione comprende un meccanismo di conformità ed uno di allocazione. In questo scritto vengono presi in considerazione tre meccanismi di conformità: ereditarietà, delega e concatenazione, e due meccanismi di allocazione: istanziazione e clonazione. L'istanziazione e l'ereditarietà sono implementati nella maggior parte dei linguaggi basati su classi come ad esempio Java; la clonazione assieme a delega o a concatenazione sono implementati prevalentemente in linguaggi basati su oggetti come rispettivamente Self e Kevo. Il confronto non può essere fatto direttamente sui linguaggi citati perché oltre al meccanismo che vogliamo analizzare possiedono altre proprietà indipendenti che condizionerebbero l'esito del confronto. Il confronto deve essere fatto alla pari isolando il meccanismo di condivisione: eliminando ovvero vincolando gli altri meccanismi in modo da ottenere tre nuclei di linguaggio sostanzialmente identici a meno del meccanismo che ci interessa. Lo scritto è organizzato in sezioni come segue. Prima descrivo i tre meccanismi di condivisione. Poi definisco informalmente i linguaggi da confrontare individuando le proprietà indipendenti e motivando la scelta di scartarle. Poi definisco sintassi, semantica e tipi dei tre linguaggi e ne dimostro l'equivalenza. Infine considero le conseguenze della equivalenza nei modelli di implementazione e di rappresentazione dei linguaggi.
Article
Full-text available
Classes are problematic in pervasive computing — systems we call "processor clouds" — where computers appear and disappear dynamically in a network. Problems with classes are mainly due to the dynamically distributed nature of these systems. The root cause of the problems is that the class- instance relationship is implicit. Two main manifestations are: state sharing vs. distribution conflicts, and inefficiencies caused by the binding of classes and their transitive closure to objects. The latter is worse in the case of statically typed languages.
Article
Full-text available
CommonLoops blends object-oriented programming smoothly and tightly with the procedure-oriented design of Lisp. Functions and methods are combined in a more general abstraction. Message passing is invoked via normal Lisp function call. Methods are viewed as partial descriptions of procedures. Lisp data types are integrated with object classes. With these integrations, it is easy to incrementally move a program between the procedure and object-oriented styles. One of the most important properties of CommonLoops is its extensive use of meta-objects. We discuss three kinds of meta-objects: objects for classes, objects for methods, and objects for discriminators. We argue that these meta-objects make practical both efficient implementation and experimentation with new ideas for object-oriented programming. CommonLoops' small kernel is powerful enough to implement the major object-oriented systems in use today.
Conference Paper
Full-text available
Two varieties of object-oriented systems exist: one based on classes as in Smalltalk and another based on exemplars (or prototypical objects) as in Act/1. By converting Smalltalk from a class based orientation to an exemplar base, independent instance hierarchies and class hierarchies can be provided. Decoupling the two hierarchies in this way enables the user's (logical) view of a data type to be separated from the implementer's (physical) view. It permits the instances of a class to have a representation totally different from the instances of a superclass. Additionally, it permits the notion of multiple representations to be provided without the need to introduce specialized classes for each representation. In the context of multiple inheritance, it leads to a novel view of inheritance (or-inheritance) that differentiates it from the more traditional multiple inheritance notions (and-inheritance). In general, we show that exemplar based systems are more powerful than class based systems. We also describe how an existing class based Smalltalk can be transformed into an exemplar-based Smalltalk and discuss possible approaches for the implementation of both and-inheritance and or-inheritance.
Article
This paper describes Symbolics’ newly redesigned object-oriented programming system, Flavors. Flavors encourages program modularity, eases the development of large, complex programs, and provides high efficiency at run time. Flavors is integrated into Lisp and the Symbolics program development environment. This paper describes the philosophy and some of the major characteristics of Symbolics’ Flavors and shows how the above goals are addressed. Full details of Flavors are left to the programmers’ manual, Reference Guide to Symbolics Common Lisp. (5).
Article
An approach to modelling intelligence in terms of communicating knowledge-based problem-solving experts is presented. The nature is investigated of the communication mechanisms needed for effective problem solving. The ability to analyze or synthesize any kind of control structure as a pattern of passing messages among the members of a society provides an important tool for understanding control structures.
Conference Paper
Inheritance and delegation are alternate methods for incremental definition and sharing. It has commonly been believed that delegation provides a more powerful model. This paper demonstrates that there is a “natural” model of inheritance which captures all of the properties of delegation. Independently, certain constraints on the ability of delegation to capture inheritance are demonstrated. Finally, a new framework which fully captures both delegation and inheritance is outlined, and some of the ramifications of this hybrid model are explored.
Conference Paper
This paper describes Symbolics' newly redesigned object-oriented programming system, Flavors. Flavors encourages program modularity, eases the development of large, complex programs, and provides high efficiency at run time. Flavors is integrated into Lisp and the Symbolics program development environment. This paper describes the philosophy and some of the major characteristics of Symbolics' Flavors and shows how the above goals are addressed. Full details of Flavors are left to the programmers' manual, Reference Guide to Symbolics Common Lisp. (5)
Article
A traditional philosophical controversy between representing general concepts as abstract sets or classes and representing concepts as concrete prototypes is reflected in a controversy between two mechanisms for sharing behavior between objects in object oriented programming languages. Inheritance splits the object world into classes, which encode behavior shared among a group of instances, which represent individual members of these sets. The class/instance distinction is not needed if the alternative of using prototypes is adopted. A prototype represents the default behavior for a concept, and new objects can re-use part of the knowledge stored in the prototype by saying how the new object differs from the prototype. The prototype approach seems to hold some advantages for representing default knowledge, and incrementally and dynamically modifying concepts. Delegation is the mechanism for implementing this in object oriented languages. After checking its idiosyncratic behavior, an ob...
Article
this paper will try to accomplish several goals (in parallel): We will argue that the actor model is an appropriate way to think about parallel computation. Since many actors may be actively sending or receiving messages at the same time, actors are inherently well suited to modelling parallel systems. We will present some specific actors which we feel should be included in the programmer's tool kit for writing parallel programs. We will show examples illustrating the use of these primitives. Futures are actors which represent the values computed by parallel processes. They can be created dynamically and disappear when they are no longer needed. Other actors may use the value of a future without concern for the feet that it was computed in parallel. Synchronization is provided by serializers, which protect actors with internal state from timing errors caused by interacting processes. We will show how these primitives have been implemented in Act 1. Act I has been implemented on a serial machine, but it simulates the kind of parallelism that would occur on a real multiprocessor machine. Discussion of the implementation will give a more concrete picture of the mechanisms involved and will also show what would be needed for an implementation on a real network of parallel processors. 12. Traditional techniques for parallelism have been inadequate