Module mechanisms have received considerable theoretical attention, but the associated concepts of separate compilation and linking have not been emphasized. Anomalous module systems have emerged in functional and object-oriented programming where software components are not separately typecheckable and compilable. In this paper we provide a context where linking can be studied, and separate compilability can be formally stated and checked. We propose a framework where each module is separately compiled to a self-contained entity called a linkset ; we show that separately compiled, compatible modules can be safely linked together.

PolyTOIL is a new statically-typed polymorphic object-oriented programming language that is provably type-safe. By separating the de nitions of subtyping and inheritance, providing a name for the type of self, and carefully de ning the type-checking rules, we have obtained a language that is very expressive while supporting modular type-checking of classes. The matching relation on types, which is related to F-bounded quanti cation, is used both in stating type-checking rules and expressing the bounds on type parameters for polymorphism. The design of PolyTOIL is based on a careful formal de nition of type-checking rules and semantics.

While simple static-typing disciplines exist for object-oriented languages like C++, Java, and Object Pascal, they are often so inflexible that programmers are forced to use type casts to get around the restrictions. At the other extreme are languages like Beta and Eiffel, which allow more freedom, but require run-time or link-time checking to pick up the type errors that their type systems are unable to detect at compile time. This paper presents a collection of sample programs which illustrate problems with existing type systems, and suggests ways of improving the expressiveness of these systems while retaining static type safety. In particular we will discuss the motivations behind introducing "MyType", "matching", and "match-bounded polymorphism" into these type systems. We also suggest a way of simplifying the resulting type system by replacing subtyping by a type system with a new type construct based on matching. Both systems provide for binary methods, which are often difficult...

Two specific problems faced in large distributed systems are: (1) evolving and managing different versions of an interface while minimizing the impact on existing clients; and (2) supporting the addition of auxiliary interfaces that are orthogonal to the main interface of an abstraction. In the context of the Spring distributed system, we addressed both problems using an object-oriented interface definition language. Different versions of an interface are represented as different types, with an inheritance relationship that minimizes the impact on existing clients, and allows easy management of versions. We distinguish between fundamental and auxiliary properties, each of which is defined as a separate type. Rather than use simple root inheritance, we use a combination of root and leaf inheritance. This provides flexibility in supporting auxiliary properties, and allows us to add new auxiliary properties as the system evolves, without forcing the system to be recompiled. The solutions have been tested and refined through their use in the Spring system.

The object-oriented paradigm of computing has started to have a significant influence on many areas of information and data processing, including database systems. This thesis focuses on the various issues and aspects governing the implementation design and development of the object model for TIGUKAT 1 , an object management system which is intended to be a full featured object-oriented database system on completion. The TIGUKAT object model [25] is behaviorally defined with a uniform object semantics. The model is behavioral in the sense that all access and manipulation of objects is restricted to the application of behaviors on objects, and it is uniform in that every entity within the model has the status of a first-class object. Various implementation design alternatives are discussed and the approaches that were chosen are justified. The ensuing implementation provides a robust kernel around which the rest of the system may be conveniently synthesized. 1 TIGUKAT(tee-goo-kat) i...