One of the most intriguing—and at the same time most problematic—notions in object-oriented programming is inheritance. Inheritance is commonly regarded as the feature that distinguishes object-oriented programming from other modern programming paradigms, but researchers rarely agree on its meaning and usage.

The Self system attempts to integrate intellectual and non-intellectual aspects of programming to create an overall experience. The language semantics, user interface, and implementation each help create this integrated experience. The language semantics embed the programmer in a uniform world of simple objects that can be modified without appealing to definitions of abstractions. In a similar way, the graphical interface puts the user into a uniform world of tangible objects that can be directly manipulated and changed without switching modes. The implementation strives to support the world-of-objects illusion by minimizing perceptible pauses and by providing true source-level semantics without sacrificing performance. As a side benefit, it encourages factoring. Although we see areas that fall short of the vision, on the whole, the language, interface, and implementation conspire so that the Self programmer lives and acts in a consistent and malleable world of objects.

Manipulating programs is hard, while manipulating objects in the physical world is often easy. Several attributes of the physical world help make it comprehensible and manipulable: concreteness, uniformity, and flexibility. The Self programming system attempts to apply these attributes to the world within the computer. The semantics of the language, the efficiency and fidelity of its implementation, and the architecture of its user interface conspire to make the experience of constructing programs in Self immediate and tangible. We describe the mechanisms used to achieve this goal, and illustrate those mechanisms within the context of an extended programming task. I.

In this paper we take a rather unusual, non-technical approach and investigate object-oriented programming and the prototype-based programming field from a purely philosophical viewpoint. Some historical facts and observations pertaining to objects and prototypes are presented, and conclusions based on those observations are derived.

Interobject references in object-oriented programs allow arbitrary aliases between objects. By breaching objects' encapsulation boundaries, these aliases can make programs hard to understand and especially hard to debug. We propose using an explicit, run-time notion of object ownership to control aliases between objects in dynamically typed languages. Dynamically checking object ownership as a program runs ensures the program maintains the encapsulation topology intended by the programmer. 1:

aimed at better supporting evolutionary software development. BOS attempts to support a spectrum of activities in one environment—ranging from rapid prototyping to code hardening. Features enabling rapid prototyping include a prototype-based object model, an interpreted language, run-time argument constraints, position and keyword arguments, and a user interface toolkit. BOS also provides features for code hardening such as multi-methods, multiple inheritance, external code wrapping mechanisms, and interfaces to other packages such as database management systems. BOS thus enables the end-toend programming of software in an integrated and unified environment. BOS has been used to develop several full-size applications which have been evaluated and delivered externally. 1.

We present and analyze the semantics and static type system for BeCecil, a theoretical (core) language with multimethods. BeCecil is a simple and orthogonal version of object-oriented languages like Cecil, CLOS, and Dylan. BeCecil has a new, simple mechanism for information hiding, which allows subclassing and yet can preserve representation invariants. BeCecil is also block-structured; within a block, one can extend a generic function with new multimethods, which may come from other generic functions. The inheritance relationships of objects may be extended in any block, and are statically scoped. The type system separates classes from types, and inheritance from subtyping. Subtype relationships are also extensible and statically scoped. These features combine to make BeCecil unusually expressive, while still allowing static typechecking.

Prototype-based languages are often described as being more flexible and expressive than class-based languages. This greater flexibility makes prototype-based languages well-suited for rapid prototyping and exploratory programming, but comes with a serious loss of safety. Examples of this are the encapsulation problem and the prototype corruption problem most prototype-based languages suffer from. These problems preclude prototypebased languages from being widely used. We propose a prototype-based language that eliminates these problems and thus reintroduces safety in prototype-based languages.

One of the advantages of prototype-based languages is that they provide self-sufficient objects which do not depend on classes or other objects for their definitions. But objects can refer to other objects, and the effects of these inter-object references introduce arbitrary, uncontrolled dependencies between objects. We propose adding an explicit notion of object ownership to control dependencies and references between objects. Object ownership can also enhance object cloning and avoid the prototype corruption problem, making programs easier to write and easier to understand.