Synchronization Expressed in Types of Communication Channels

. Static typing and subtyping are useful concepts in objectoriented programming languages. Unfortunately, current type models for concurrent object-oriented languages are not yet as expressive as they should be: Clients have to rely on synchronization behavior not expressed in the objects' types. In the type model proposed in this paper, types of communication channels make synchronization constraints explicit. Static type-checking ensures that messages are sent only if the receivers can deal with the messages at the time when they are received, although the set of accepted messages can change dynamically. 1 Introduction Static typing is useful to increase the readability and reliability of programs and allows the compiler to incorporate additional optimizations. Subtyping supports the reuse of concepts expressed in types. In this paper we investigate a model for statically typed, concurrent, object-oriented programming languages. The objects are regarded as processes (i.e. active obj..

Types that Reflect Changes of Object Usability

. Strong, static typing is useful because it can improve the readability, reliability and optimizability of programs. The usability of an object may change over time. However, conventional type systems for object-oriented languages presume that objects are always used in the same way. In this paper an extension of Ada's type concept is presented: Possible changes of object usabilities can be specified as part of type declarations for passive and active objects. This extension is compatible with inheritance and supports static type checking. 1 Introduction Statically typed programming languages associate each expression in a program with a type statically derivable from the program. Strongly typed languages ensure that type errors cannot occur at run time [2]. Most programming languages used in practice are (at least in part) statically and strongly typed because static, strong typing can increase the readability and reliability of programs and supports optimizations. In object-oriente..

Flexible Types for a Concurrent Model

Subtyping is undoubtedly useful for the support of incremental refinement and reuse of software components, a crucial feature of object-oriented languages. Types and subtyping for concurrent languages are not yet explored sufficiently and tend to be less flexible than desired. We propose a principle of dealing with very flexible types in concurrent languages. The corresponding type model ensures that "message not understood " errors cannot occur even if object behavior can be dynamically modified in some ways. 1 Introduction The basic concept of object-oriented programming languages is that of objects communicating with other objects [4, 17]. An object is a self-contained entity characterized by its identity, state and behavior. The objects are classified according to their behavior into a system of types. We regard also subtyping [5, 10] and the related sort of polymorphism (inclusion polymorphism) as necessary features of object-oriented languages. In concurrent object-oriented lan..

Synchronization with Type Variables

Although Java is supposed to be a language for the Internet, there is only marginal support of concurrency and synchronization. Especially the reliability of concurrent Java programs is quite often problematic. We propose to use a language with much more reliable synchronization concepts based on process types. This approach gives more flexibility and allows us to use inheritance and subtyping in concurrent programs in the same way as in sequential programs

In Components We Trust – Programming Language Support for Weak Protection

For many reasons we trust components just to some degree. Component users apply a number of methods to improve protection against malicious components. In this paper we briefly analyze some of these concepts and their relationships to our trust in components. It turns out that weak protection methods (those with potential security holes) can be beneficial for components we partially trust especially if potential holes are clearly visible. Visible holes build a basis for extending responsibility from the component user to the component supplier.

Black & White, Never Grey: On Interfaces, Synchronization, Pragmatics, and Responsibilities

When composing systems from components we have to deal with involved aspects like synchronization or non-functional properties like performance. It is nearly impossible to clearly specify such aspects in interfaces. Looking behind the interfaces (into grey boxes) does not solve the problem because of lost substitutability. In this paper we explain on the example of synchronization, first, how pragmatic descriptions solve the problem in usual cases and, second, that moving and splitting responsibility for synchronization between components is helpful in further cases. We argue that there is a general pattern applicable to many functional and nonfunctional aspects behind this solution.

Type Specifications with Processes

Object-oriented software development is characterized by the repeated refinement of specifications and software components. The refinement of specifications is facilitated by the use of specification languages which support subtyping based on the principle of substitutability. In this paper we propose to specify concurrent systems by types represented as expressions of a process calculus. These types allow to specify also dynamic language aspects and still support subtyping and static type-checking. Keywords type specification, subtyping, static type checking, process calculi 1 INTRODUCTION Specifications have long been a cornerstone in the development of reliable software and will continue to receive much attention if there are appropriate specification techniques that can be adapted to the characteristics of the specified software and the software development process. The current trend in software development follows the object-oriented paradigm characterized by a hierarchical clas..

Dynamic Type Information in Process Types

. Static checking of process types ensures that each object accepts all messages received from concurrent clients, although the set of acceptable messages can depend on the object's state. However, conventional approaches of using dynamic type information (e.g., checked type casts) are not applicable in the current process type model, and the typing of self-references is too restrictive. In this paper a refinement of the model is proposed. It solves these problems so that it is easy to handle, for example, heterogeneous collections. 1 Introduction The process type model was proposed as a statically checkable type model for concurrent and distributed systems based on active objects [Pun96,Pun97]. A process type specifies not only a set of acceptable messages, but also constraints on the sequence of these messages. Type safety can be checked statically by ensuring that each object reference is associated with an appropriate type mark which specifies all message sequences accepted by th..