In several works on design methodologies, design patterns, programming language design and application frameworks, the need for adequate higher-level program entities that capture the patterns of collaboration between several classes has been recognized. The idea is that in general the unit of reuse is not a single class, but a slice of behavior affecting a set of collaborating classes. The absence of large-scale components for expressing these collaborations makes object-oriented programs more difficult to maintain and reuse, because functionality is spread over several methods and it becomes difficult to get the "big picture". In this paper, we propose Adaptive Plug and Play Components to serve this need. These components are designed such that they not only facilitate the construction of complex software by making the collaborations explicit, but they do so in a manner that supports the evolutionary nature of both structure and behavior. 1 Introduction The step from proc...

Abstract. The design of many popular object-oriented languages like Smalltalk, Eiffel, or Sather follows a certain trend: The class is the only structuring form. In this paper, the need for having modules besides classes is claimed. Modules stem from a different language family and at first glance it seems that they can easily be unified with classes. Among other things, unifying modules and classes carries the danger of unifying the import and inheritance relationships. Constructs in several languages are discussed that indicate that modules and classes should indeed be kept separate. 1 Introduction and Clarification of Terms Among other things, the quality of a programming language may be judged by the number, orthogonality, and completeness of its concepts. The first measure is as simple as counting; the second and third are far more difficult to determine. Orthogonality is important to avoid confusion; concept overlaps should at least be kept small. In practice, completeness is a

A technique for representing programs abstractly and independently of the eventual target architecture is presented that yields a file representation twice as compact as machine code for a CISC processor. It forms the basis of an implementation, in which the process of code generation is deferred until the time of loading. At that point, native code is created on_the_fly by a code_generating loader. The process of loading with dynamic code_generation is so fast that it requires little more time than the input of equivalent native code from a disk storage medium. This is predominantly due to the compactness of the abstract program representation, which allows to counterbalance the ad...

Software systems have been using “just-in-time ” compilation (JIT) techniques since the 1960s. Broadly, JIT compilation includes any translation performed dynamically, after a program has started execution. We examine the motivation behind JIT compilation and constraints imposed on JIT compilation systems, and present a classification scheme for

The programming language Oberon is the result of a concentrated effort to increase the power of Modula-2 and simultaneously to reduce its complexity. Several features were eliminated, and a few were added in order to increase the expressive power and flexibility of the language. This paper describes and motivates the changes. The language is defined in a concise report. Introduction The programming language Oberon evolved from a project whose goal was the design of a modern, flexible, and efficient operating system for a single-user workstation. A principal guideline was to concentrate on properties that are genuinely essential and - as a consequence - to omit ephemeral issues. It is the best way to keep a system in hand, to make it understandable, explicable, reliable, and efficiently implementable. Initially, it was planned to express the system in Modula-2 [1] (subsequently called Modula), as that language supports the notion of modular design quite effectively, and because an oper...

Oberon-2 is a refined version of Oberon developed at ETH. It introduces type-bound procedures, read-only export of data, and open array variables. The For statement is reintroduced. This paper concentrates on type-bound procedures which make Oberon-2 an object-oriented language with dynamically-bound messages and strong type checking at compile time. Messages can also be sent as data packets (extensible records) that are passed to a handler procedure and are interpreted at run time. This is as flexible as the Smalltalk message dispatching mechanism. Objects carry type information at run time which allows dynamic binding of messages, run time type tests, and the implementation of persistent objects. Oberon-2 is available on various machines. OVERVIEW In 1987, Wirth defined the language Oberon [1]. Compared with its predecessor Modula-2, Oberon is smaller and cleaner, and it supports type extension which is a prerequisite for object-oriented programming. Type extension allows the progra...

This paper describes the structure of the compiler, summarizes the experience gained in adapting it for various CISC and RISC processors, and presents some empirical performance data. It also sheds light on the task of grafting an operating environment onto a variety of existing operating systems

Using an object-oriented approach, the text editor Write has been designed to be extensible while its basic structure has been kept small and simple. As its main extension concept, Write supports extensible objects floating in a text. An important result presented is that the extended editor can play the role of various dedicated applications. It can be stated that the editor together with its extension model constitutes an application framework of rather wide applicability. This paper presents the editing model chosen for Write and its effects on efficiency and ease of extension. To demonstrate the effectiveness of the approach, several editor extensions are presented. Keywords Extensible Editor, Application Framework, Write, Oberon 2 Introduction A framework is the common design of (a class) of similar applications or subsystems [Johnson 88]. The design of frameworks is by no means easy. To cite [Deutsch 89]: "Interface design and functionality factoring constitutes the key intell...

. A machine_independent abstract program representation is presented that is twice as compact as machine code for a CISC processor. It forms the basis of an implementation, in which the process of code generation is deferred until the time of loading. Separate compilation of program modules with type_safe interfaces, and dynamic loading (with code generation) on a per_module basis are both supported. To users of the implemented system, working with modules in the abstract representation is as convenient as working with native object_files, although it leads to several new capabilities. The combination of portability with practicality denotes a step toward a software component industry. 1. Introduction The rapid evolution of hardware technology is constantly influencing software development, for better as well as for worse. On the downside, faster hardware can conceal the complexity and cost of badly_designed programs; Reiser [Rei89] is not far off the mark in observing that s...

Safe languages provide mechanisms to share data among multiple protection domains in a protected fashion, but lack support for revocation and control over resource usage. This paper describes a type system extension, called permits, to support the revocation of data structures. Permits use a combination of static and run-time checks to ensure the revocability of data shared between safe language tasks, with a minimum of run-time overhead. The paper presents the syntax for this extension formally, and summarizes our experience with implementing the type system in a real language. 1 Introduction Several recent projects have proposed using type-safe languages to provide security for extensible systems that run in a single address space. For example, SPIN[BSP+95] allows extensions written in Modula-3 to run in the operating system kernel, Java applets[WBD97] extend a web browser, and extensible web servers load Java servlets[Jav] into the server's address space. We'll describe such ...