Introduction

The work on Omega started in 1990 as a research project. The original goal was to create a simple yet powerful pure object-oriented programming language in the spirit of Smalltalk [Goldberg 1984] and Self [Ungar 1987]. The idea of prototypes, as implemented in Self, was deemed promising for the construction of object-oriented software. In a prototype-based language, new objects are created by simply cloning an existing object. A new "class" of objects is created by creating a new object (a prototype) and defining the object's structure, behaviour, and initial contents. All these properties are directly attached to the prototypical object. Classes in the sense of Smalltalk or C++ [Stroustrup 1986] are not needed.


Another goal of the Omega project was to achieve the highest possible degree of safety by means of static typing. As many programming errors as possible should be detected at compile time. Unfortunately, Self's delegation approach and the possibility to modify the structure and/or behaviour of individual objects make static typing impossible. It was therefore necessary to find another way of implementing prototypes. The solution was to use traditional inheritance rather than delegation and to distinguish prototypes from other objects. In contrast to a "regular" object, a prototype has a name that also serves as a type name in declarations. When a prototype's structure and/or behaviour is modified, the modification affects not only the prototypical object itself but also all existing objects that have been cloned directly or indirectly from the prototype.
As soon as static typing was implemented in Omega, it became apparent that some sort of genericity was needed to allow for convenient implementation of object collections. The prototype concept also influenced the way in which genericity was introduced in Omega. In Eiffel [Meyer 1988, 1992], a generic class is an incomplete class with some holes that must be filled in order to get a useable class from which objects can be instantiated. In contrast, a generic prototype in Omega is already a useable object with an associated default type. For example, the Array prototype is associated with the default element type Object, which means that Array and its clones can be filled with arbitrary objects. Omega's concept of genericity allows to create a new prototype by replacing the general default type with a more specific type. For example, Array{Window} and its clones can only be filled with objects of type Window or of any subtype of Window.
The language itself is rather small. The syntax of Omega is defined by not more than 29 EBNF rules. The language itself does not even contain operators on elementary data types or control flow elements. In Smalltalk-like fashion, all these "language features" are provided by the prototype library. The library does not only contain static descriptions of the prototypes but rather is a collection of objects (in particular, prototypes) that are stored in a workspace file (similar to a Smalltalk image).
When working with prototypes, it is essential that prototypes can be constructed and the structure and behavior of prototypes can be defined interactively. It is therefore not possible to separate the Omega language from the Omega programming environment. An Omega program consists of a set of objects within a workspace. The programming environment enables the programmer to interactively inspect and modify all parts of a workspace.
The following sections describe the Omega language, the programming environment and the library in more detail. It must be noted that this description is by no means complete. It rather concentrates on the key concepts of the whole Omega system and tries to give the reader an impression of a typical Omega programming style by means of examples. A complete description of the Omega system can be found in [Blaschek 1994].
Following Sections:


This page has been visited times.