No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Polymorphic Identifiers: Uniform Resource Access in Objective-Smalltalk
Abstract
In object-oriented programming, polymorphic dispatch of operations decouples clients from specific providers of services and allows implementations to be modified or substituted without affecting clients.
The Uniform Access Principle (UAP) tries to extend these qualities to resource access by demanding that access to state be indistinguishable from access to operations. Despite language features supporting the UAP, the overall goal of substitutability has not been achieved for either alternative resources such as keyed storage, files or web pages, or for alternate access mechanisms: specific kinds of resources are bound to specific access mechanisms and vice versa. Changing storage or access patterns either requires changes to both clients and service providers and trying to maintain the UAP imposes significant penalties in terms of code-duplication and/or performance overhead.
We propose introducing first class identifiers as polymorphic names for storage locations to solve these problems. With these Polymorphic Identifiers, we show that we can provide uniform access to a wide variety of resource types as well as storage and access mechanisms, whether parametrized or direct, without affecting client code, without causing code duplication or significant performance penalties.
... Storage combinators are specific kinds of stores, objects that implement a storage-oriented interface modelled on the REST verbs and very similar to dictionary APIs. Stores 2 iOS programs are not allowed to have multiple processes were introduced in Polymorphic Identifiers [48] and abstract over different kinds of storage, such as files, databases and dictionaries. Storage combinators specialise stores in that they don't just provide the storage interface to their clients, but in turn use the storage API themselves to fetch and store data. ...
... Polymorphic Identifiers in Objective-Smalltalk [48] are used to identify the location of a resource. They serve the same role in In-Process REST as URIs for REST/HTTP and are closely modeled on URIs. ...
... The benefits of decoupling clients from specific storage implementations via a uniform protocol roughly correspond to the general benefits of loose coupling in software engineering [50] and were discussed in detail in Polymorphic Identifiers: Uniform Resource Access in Objective-Smalltalk [48]. ...
The ability to compose software from high level components is as sought after as it is elusive. The REST architectural style used in the World Wide Web enables such plug-compatible components in distributed settings.
We propose storage combinators, a type of plug-compatible component that can be used as generic intermediary in a non-distributed setting.
Storage combinators combine several stores – components that support REST-style verbs – into a single component that also provides a store interface.
This mechanism allows a few basic components to be combined in many different ways to achieve different effects with or without adaptation. It correlates with reported increases in productivity while performing well in commercial applications with millions of users.
... Polymorphic identifiers The concept of polymorphic identifiers [30] generalizes lefthand values and associates them with schema handlers that deal with how a value is written to read from the storage location pointed to by the identifier. If identifiers for methods, instance variables, and global variables (e.g. ...
Live programming environments enable programmers to edit a running program and obtain immediate feedback on each individual change. The liveness quality is valued by programmers to help work in small steps and continuously add or correct small functionality while maintaining the impression of a direct connection between each edit and its manifestation at run-time. Such immediacy may conflict with the desire to perform a combined set of intermediate steps, such as a refactoring, without immediately taking effect after each individual edit. This becomes important when an incomplete sequence of small-scale changes can easily break the running program. State-of-the-art solutions focus on retroactive recovery mechanisms, such as debugging or version control. In contrast, we propose a proactive approach: Multiple individual changes to the program are collected in an \emph{Edit Transaction}, which can be made effective if deemed complete. Upon activation, the combined steps become visible together. \emph{Edit Transactions} are capable of dynamic scoping, allowing a set of changes to be tested in isolation before being extended to the running application. This enables a live programming workflow with full control over change granularity, immediate feedback on tests, delayed effect on the running application, and coarse-grained undos. We present an implementation of \emph{Edit Transactions} along with \emph{Edit-Transaction}-aware tools in Squeak/Smalltalk. We asses this implementation by conducting a case study with and without the new tool support, comparing programming activities, errors, and detours for implementing new functionality in a running simulation. We conclude that workflows using \emph{Edit Transactions} have the potential to increase confidence in a change, reduce potential for run-time errors, and eventually make live programming more predictable and engaging.
The architecture of interactive systems does not match the procedural decomposition mechanisms available in most programming languages, leading to architectural mismatch. Constraint systems have been used only as black boxes for computing with primitive values of a specific type and for specific domains such as user interface layouts or program compilation. We propose constraints as a general purpose architectural connector for both describing the large-scale structure of interactive systems and matching that description with the actual implementation.
Most ideas come from previous ideas. The sixties, particularly in the ARPA community, gave rise to a host of notions about “human-computer symbiosis” through interactive time-shared computers, graphics screens and pointing devices. Advanced computer languages were invented to simulate complex systems such as oil refineries and semi-intelligent behavior. The soon to follow paradigm shift of modern personal computing, overlapping window interfaces, and object-oriented design came from seeing the work of the sixties as something more than a “better old thing”. That is, more than a better way: to do mainframe computing; for end-users to invoke functionality; to make data structures more abstract. Instead the promise of exponential growth in computing/$/volume demanded that the sixties be regarded as “ almost a new thing” and to find out what the actual “new things” might be. For example, one would compute with a handheld “Dynabook” in a way that would not be possible on a shared mainframe; millions of potential users meant that the user interface would have to become a learning environment along the lines of Montessori and Bruner; and needs for large scope, reduction in complexity, and end-user literacy would require that data and control structures be done away with in favor of a more biological scheme of protected universal cells interacting only through messages that could mimic any desired behavior.
Early Smalltalk was the first complete realization of these new points of view as parented by its many predecessors in hardware, language and user interface design. It became the exemplar of the new computing, in part, because we were actually trying for a qualitative shift in belief structures—a new Kuhnian paradigm in the same spirit as the invention of the printing press—and thus took highly extreme positions which almost forced these new styles to be invented.
We describe support for modularity in Newspeak, a programming language descended from Smalltalk [33] and Self [69]. Like Self,
all computation — even an object’s own access to its internal structure — is performed by invoking methods on objects. However,
like Smalltalk, Newspeak is class-based. Classes can be nested arbitrarily, as in Beta [44]. Since all names denote method
invocations, all classes are virtual; in particular, superclasses are virtual, so all classes act as mixins. Unlike its predecessors,
there is no static state in Newspeak, nor is there a global namespace. Modularity in Newspeak is based exclusively on class
nesting. There are no separate modularity constructs such as packages. Top level classes act as module definitions, which
are independent, immutable, self-contained parametric namespaces. They can be instantiated into modules which may be stateful
and mutually recursive.
This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decompositions are discussed. The unconventional decomposition, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.
Permission is hereby granted to make and distribute verbatim copies of this document without royalty or fee. Permission is granted to quote excerpts from this documented provided the original source is properly cited. ii When separately written programs are composed so that they may cooperate, they may instead destructively interfere in unanticipated ways. These hazards limit the scale and functionality of the software systems we can successfully compose. This dissertation presents a framework for enabling those interactions between components needed for the cooperation we intend, while minimizing the hazards of destructive interference. Great progress on the composition problem has been made within the object paradigm, chiefly in the context of sequential, single-machine programming among benign components. We show how to extend this success to support robust composition of concurrent and potentially malicious components distributed over potentially malicious machines. We present E, a distributed, persistent, secure programming language, and CapDesk, a virus-safe desktop built in E, as embodiments of the techniques we explain.
SELF is an object-oriented language for exploratory programming based on a small number of simple and concrete ideas: prototypes, slots, and behavior. Prototypes combine inheritance and instantiation to provide a framework that is simpler and more flexible than most object-oriented languages. Slots unite variables and procedures into a single construct. This permits the inheritance hierarchy to take over the function of lexical scoping in conventional languages. Finally, because SELF does not distinguish state from behavior, it narrows the gaps between ordinary objects, procedures, and closures. SELF's simplicity and expressiveness offer new insights into object-oriented computation.
To thine own self be true. — William Shakespeare laggy
Most ideas come from previous ideas. The sixties, particularly in the ARPA community, gave rise to a host of notions about "human-computer symbiosis" through interactive time-shared computers, graphics screens, and pointing devices. Advanced computer languages were invented to simulate complex systems such as oil refineries and semi-intelligent behavior. The soon to follow paradigm shift of modern personal computing, overlapping window interfaces, and object-oriented design came from seeing the work of the sixties as something more than a "better old thing." That is, more than a better way: to do mainframe computing; for end-users to invoke functionality; to make data structures more abstract. Instead the promise of exponential growth in computing/$/volume demanded that the sixties be regarded as "almost a new thing" and to find out what the actual "new things" might be. For example, one would compute with a handheld "Dynabook" in a way that would not be possible on a shared main-frame; millions of potential users meant that the user interface would have to become a learning environment along the lines of Montessori and Bruner; and needs for large scope, reduction in complexity, and end-user literacy would require that data and control structures be done away with in favor of a more biological scheme of protected universal cells interacting only through messages that could mimic any desired behavior.Early Smalltalk was the first complete realization of these new points of view as parented by its many predecessors in hardware, language, and user interface design. It became the exemplar of the new computing, in part, because we were actually trying for a qualitative shift in belief structures---a new Kuhnian paradigm in the same spirit as the invention of the printing press---and thus took highly extreme positions that almost forced these new styles to be invented.
Fault tolerant and secure operating systems are a worthwhile goal. Ak nown method for accomplishing fault tolerance and security is isolation. This means running separate operating system services in separate protection domains so that theyc annot interfere with each other,a nd can communicate only via well-defined messaging inter-faces. Isolation and message passing brings inherent overhead when compared to ser-vices doing communication by accessing each others memory directly.T oa ddress this, the ultimate goal would be to be able to run the kernel subsystems in separate domains during development and testing, but have a drop-in availability to maket hem run in ker-nel mode for performance critical application scenarios. Still today,m ost operating sys-tems are written purely with C and some assembly using the monolithic kernel approach, where all operating system code runs within a single protection domain. Asingle error in anysubsystem can bring the whole operating system down. This work presents puffs -the Pass-to-Userspace Framework File System -shipped with the NetBSD Operating System. It is a framework for implementing file systems out-side of the kernel in a separate protection domain in a user process. The implementation is discussed in-depth for a kernel programmer audience. The benefits in implementation simplicity and increased security and fault tolerance are argued to outweigh the measured overhead when compared with a classic in-kernel file system. Ac oncrete result of the work is a completely BSD-licensed sshfs implementation.
Python is a simple, yet powerful, interpreted programming language that bridges the gap between C and shell programming, and is thus ideally suited for ``throw-away programming'''' and rapid prototyping. Its syntax is put together from constructs borrowed from a variety of other languages; most prominent are influences from ABC, C, Modula-3 and Icon. The Python interpreter is easily extended with new functions and data types implemented in C. Python is also suitable as an extension language for highly customizable C applications such as editors or window managers. Python is available for various operating systems, amongst which several flavors of UNIX (including Linux), the Apple Macintosh O.S., MS-DOS, MS-Windows 3.1, Windows NT, and OS/2. This reference manual describes the syntax and ``core semantics'''' of the language. It is terse, but attempts to be exact and complete. The semantics of non-essential built-in object types and of the built-in functions and modules are described in the Python Library Reference. For an informal introduction to the language, see the Python Tutorial.
Theinfluential pure embedding methodology of embedding domain- specific languages (DSLs) as libraries into a general-purpose host language forces the DSL designer to commit to a single semantics. This precludes the subsequent addition of compilation, optimiza- tion or domain-specific analyses. We propose polymorphic embed- ding of DSLs, where many different interpretations of a DSL can be provided as reusable components, and show how polymorphic embedding can be realized in the programming language Scala. With polymorphic embedding, the static type-safety, modularity, composability and rapid prototyping of pure embedding are recon- ciled with the flexibility attainable by external toolchains.
Embedded domain-specific languages (EDSLs) are said to be easier to compose than DSLs that are implemented by preprocessors. However, existing approaches focus on composition scenarios where the use of abstractions from one domain does not affect the interpretation of abstractions from another domain. This leads to programs that exhibit scattering and tangling symptoms if multiple EDSLs with crosscutting domain semantics are used. To address this issue, we propose an architecture for embedding DSLs that makes use of meta-object protocols and aspect-oriented concepts to support crosscutting composition of EDSLs. This enables to write modularized EDSL programs where each program addresses one concern.
Several efforts have been made over the years for developing file systems in user space. Many of these efforts have failed to make a significant impact as measured by their use in production systems. Recently, however, user space file systems have seen a strong resurgence. FUSE is a popular framework that allows file systems to be developed in user space while offering ease of use and flexibility. In this paper, we discuss the evolution of user space file systems with an emphasis on FUSE, and measure its performance using a variety of test cases. We also discuss the feasibility of developing file systems in high-level programming languages, by using as an example Java bindings for FUSE that we have developed. Our benchmarks show that FUSE offers adequate performance for several kinds of workloads.
Plan 9 is a distributed system built at the Computing Sciences Research Center of AT&T Bell Laboratories over the last few years. Its goal is to provide a production-quality system for software development and general computation using heterogeneous hardware and minimal software. A Plan 9 system comprises CPU and file servers in a central location connected together by fast networks. Slower networks fan out to workstation-class machines that serve as user terminals. Plan 9 argues that given a few carefully implemented abstractions it is possible to produce a small operating system that provides support for the largest systems on a variety of architectures and networks. The foundations of the system are built on two ideas: a per-process name space and a simple message-oriented file system protocol.
Plan 9 is a distributed system built at the Computing Sciences Research Center of AT&T Bell Laboratories (now Lucent Technologies, Bell Labs) over the last few years. Its goal is to provide a production-quality system for software development and general computation using heterogeneous hardware and minimal software. A Plan 9 system comprises CPU and file servers in a central location connected together by fast networks. Slower networks fan out to workstation-class machines that serve as user terminals. Plan 9 argues that given a few carefully implemented abstractions it is possible to produce a small operating system that provides support for the largest systems on a variety of architectures and networks. The foundations of the system are built on two ideas: a perprocess name space and a simple message-oriented file system protocol. The operating system for the CPU servers and terminals is structured as a traditional kernel: a single compiled image containing code for resou...
This paper forms the substance of a course of lectures given at the International Summer School in Computer Programming at Copenhagen in August, 1967. The lectures were originally given from notes and the paper was written after the course was finished. In spite of this, and only partly because of the shortage of time, the paper still retains many of the shortcomings of a lecture course. The chief of these are an uncertainty of aim—it is never quite clear what sort of audience there will be for such lectures—and an associated switching from formal to informal modes of presentation which may well be less acceptable in print than it is natural in the lecture room. For these (and other) faults, I apologise to the reader.
There are numerous references throughout the course to CPL [1–3]. This is a programming language which has been under development since 1962 at Cambridge and London and Oxford. It has served as a vehicle for research into both programming languages and the design of compilers. Partial implementations exist at Cambridge and London. The language is still evolving so that there is no definitive manual available yet. We hope to reach another resting point in its evolution quite soon and to produce a compiler and reference manuals for this version. The compiler will probably be written in such a way that it is relatively easyto transfer it to another machine, and in the first instance we hope to establish it on three or four machines more or less at the same time.
The lack of a precise formulation for CPL should not cause much difficulty in this course, as we are primarily concerned with the ideas and concepts involved rather than with their precise representation in a programming language.
Object-Oriented Software Construction, second edition is the comprehensive reference on all aspects of object technology, from design principles to O-O techniques, Design by Contract, O-O analysis, concurrency, persistence, abstract data types and many more. Written by a pioneer in the field, contains an in-depth analysis of both methodological and technical issues.
Field accessor methods have become a ubiquitous feature of object-oriented programming. The definition and use of such methods promote code bloat and an unnatural expression style. We propose a simple addition to the C++ language that can move the burden of providing abstraction support for fields from the programmer to the compiler.
A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808.
this paper I will describe the results of using the functional language Haskell to build DSELs. Haskell has several features that make it particularly suitable for this, but other languages could also be used. On the other hand, there are features that don't exist in any language (to my knowledge) that would make things even easier; there is much more work to be done. Domain Specific Semantics It is surprisingly straightforward to design a DSEL for many specific applications. We have done so already using Haskell in several domains: parser generation, graphics, animation, simulation, music composition, and geometric region analysis, to -- Geometric regions are represented as functions: type Region = Point -? Bool -- so to test a point's membership in a region, we do: inRegion :: Point -? Region -? Bool p `inRegion` r = r p -- Given suitable definitions of "circle", "outside", and /": circle :: Radius -? Region -- creates a region with given radius outside :: Region -? Region -- the logical negation of a region (/") :: Region -? Region -? Region -- the intersection of two regions -- we can then define a function to generate an annulus: annulus :: Radius -? Radius -? Region annulus r1 r2 = outside (circle r1) /" circle r2 Figure 1: Example of a DSEL for a Naval Application name a few. The latter domain---geometric region analysis---came about through an experiment conducted jointly by Arpa, ONR, and the Naval Surface Warfare Center. This well-documented experiment (see [Car93, CHJ93, LBK
In a distributed system networks are of paramount importance. This paper describes the implementation, design philosophy, and organization of network support in Plan 9. Topics include network requirements for distributed systems, our kernel implementation, network naming, user interfaces, and performance. We also observe that much of this organization is relevant to current systems. 1. Introduction Plan 9 [Pike90] is a general-purpose, multi-user, portable distributed system implemented on a variety of computers and networks. What distinguishes Plan 9 is its organization. The goals of this organization were to reduce administration and to promote resource sharing. One of the keys to its success as a distributed system is the organization and management of its networks. A Plan 9 system comprises file servers, CPU servers and terminals. The file servers and CPU servers are typically centrally located multiprocessor machines with large memories and high speed interconnects. A vari...
Concerns on identifier confusion inmboxCommon LISP
- R P Gabriel
Resource-Oriented Computing with NetKernel. O'Reilly Media
- T Geudens
EiffelWorld Column. URL http://www.eiffel.com/general/column
- B Meyer
Programming in Objective-C 2.0
- Stephen Kochan
Programming in Scala: A Comprehensive Step-by-step Guide
- M Odersky
- L Spoon
- B Venners
Microsoft Press Redmond WA USA 2nd edition
- T Archer
Obsoleted by RFCs 4248 4266 updated by RFCs 1808 2368 2396 3986 6196 6270
- T Berners-Lee
- L Masinter
- M Mccahill
RFC 6570 (Proposed Standard
- Gregorio R Fielding
- M Hadley
- M Nottingham
- D Orchard
- Template
Upper Saddle River NJ USA 1st edition 1988. ISBN 0136290493. B. Meyer. Object-Oriented Software Construction
- B Meyer