A Core Calculus of Classes and Mixins

2004

This work presents an object-oriented calculus based on higher-order mixin construction via mixin composition, where some software engineering requirements are modeled in a formal setting allowing to prove the absence of message-not-understood run-time errors. Mixin composition is shown to be a valuable language feature enabling a cleaner object-oriented design and development. In what we believe being quite a general framework, we give directions for designing a programming language equipped with higher-order mixins, although our study is not based on any already existing object-oriented language.

Lecture Notes in Computer Science, 1998

This paper presents an imperative object calculus designed to support class-based programming via a combination of extensible objects and encapsulation. This calculus simpli es the language presented in 17] in that, like C++ and Java, it chooses to support an imperative semantics instead of method specialization. We show how Java-style classes and \mixins" may be coded in this calculus, prove a type soundness theorem (via a subject reduction property), and give a sound and complete typing algorithm.

We design a calculus that combines class-based features with object-based ones, with the aim of fitting into a unifying setting the "best of both worlds". In a mixin-based approach, mixins are seen as incomplete classes from which incomplete objects can be instantiated. In turn, incomplete objects can be completed in an object-based fashion. Our hybrid calculus is shown to be useful in some real world scenarios that we present as examples.

1995

[1993] Proceedings Eighth Annual IEEE Symposium on Logic in Computer Science, 1993

This paper presents an untyped lambda calculus, extended with object primitives that reflect the capabilities of so-called delegation-based object-oriented languages. A type inference system allows static detection of errors, such as message not understood, while at the same time allowing the type of an inherited method to be specialized to the type of the inheriting object. Type soundness is proved using operational semantics and examples illustrating the expressiveness of the pure calculus are presented.

2006

Solid theoretical foundation of object-oriented paradigm have been developed for both functional and imperative programming languages. Although type theory contains functional programming language and offers rich specification and reasoning capabilities the similar foundation is not so evident despite the presence of flavor of object orientation in many other formal methods.

The diverse inheritance mechanisms provided by Smalltalk, Beta, and CLOS are interpreted as different uses of a single underlying construct. Smalltalk and Beta differ primarily in the direction of class hierarchy growth. These inheritance mechanisms are subsumed in a new inheritance model based on composition of mixins, or abstract subclasses. This form of inheritance can also encode a CLOS multiple-inheritance hierarchy, although changes to the encoded hierarchy that would violate encapsulation are difficult. Practical application of mixin-based inheritance is illustrated in a sketch of an extension to Modula-3.

We present an operational semantics and a typing assignment system for the concurrent object-oriented speci cation language Gnome, based on a name-passing asynchronous calculus of concurrent objects, TyCO. The operational semantics is given by a map encoding Gnome classes in TyCO agents, and thus, objects (instances of classes) in processes (instances of agents). We propose a general approach to implement synchronous communication in an asynchronous process calculus, using a commit-abort protocol, achieving by this means the synchronization of all objects involved on a transaction. We treat objects with internal animation, their dynamic creation and deletion. Furthermore, the method generates a (decidable) typing assignment system that ensures lack of runtime errors for typable programs. The type of an agent certi cates the communicating protocol of the corresponding class.

Journal of Functional Programming, 1994

To illuminate the fundamental concepts involved in object-oriented programming languages, we describe the design of TOOPL, a paradigmatic, statically-typed, functional, object-oriented programming language which supports classes, objects, methods, hidden instance variables, subtypes and inheritance. It has proven to be quite difficult to design such a language which has a secure type system. A particular problem with statically type checking object-oriented languages is designing typechecking rules which ensure that methods provided in a superclass will continue to be type correct when inherited in a subclass. The type-checking rules for TOOPL have this feature, enabling library suppliers to provide only the interfaces of classes with actual executable code, while still allowing users to safely create subclasses. To achieve greater expressibility while retaining type-safety, we choose to separate the inheritance and subtyping hierarchy in the language. The design of TOOPL has been guided by an analysis of the semantics of the language, which is given in terms of a model of the F-bounded second-order lambda calculus with fixed points at both the element and type level. This semantics supports the language design by providing a means to prove that the type-checking rules are sound, thus guaranteeing that the language is type-safe. While the semantics of our language is rather complex, involving fixed points at both the element and type level, we believe that this reflects the inherent complexity of the basic features of object-oriented programming languages. Particularly complex features include the implicit recursion inherent in the use of the keyword, self, to refer to the current object, and its corresponding type, MyType. The notions of subclass and inheritance introduce the greatest semantic complexities, whereas the notion of subtype is more straightforward to deal with. Our semantic investigations lead us to recommend caution in the use of inheritance, since small changes to method definitions in subclasses can result in major changes to the meanings of the other methods of the class.