Component-based software, open systems, and document-based user interfaces are about to revolutionise most areas traditionally addressed by the software engineer. We claim that many traditional software engineering methods, from life-cycle models to programming languages to system architectures are at least insufficient when facing the new trends. In this paper we present the main points of criticism and state a few unavoidable facts of life: extensible systems are in principle modular, have no final form or final integration phase, cannot be subjected to final total analysis, cannot be exhaustively tested, and have to allow for mutual independence of extension providers. We also hint at possible solutions for part of the problem set. In particular, we investigate the problem of dependence on global analysis, the effects of Cartesian Products in the design space, and the resulting design constraints on programming languages as the exemplary and most important tool of the software engi...

Sather 1.0 is a programming language whose design has resulted from the interplay of many criteria. It attempts to support a powerful object-oriented paradigm without sacrificing either the computational performance of traditional procedural languages or support for safety and correctness checking. Much of the engineering effort went into the design of the class and type system. This paper describes some of these design decisions and relates them to approaches taken in other languages. We particularly focus on issues surrounding inheritance and subtyping and the decision to explicitly separate them in Sather. ICSI, E-mail: szyper@icsi.berkeley.edu. y ICSI, E-mail: om@icsi.berkeley.edu. z ICSI and Eidgenossische Technische Hochschule (ETH), Zurich, Switzerland. E-mail: murer@icsi.berkeley.edu. ii 1 Introduction Sather is an object-oriented language developed at the International Computer Science Institute [22]. It has a clean and simple syntax, parameterized classes, object-o...

In this, the eighteenth article in a regular series on object-oriented type theory, we look at how object-oriented languages might evolve in the future, given that the formal notion of class is now better understood than at the outset. Object-oriented languages were the first family to suppose that there might be systematic sets of relationships between all the

This report describes the three programming languages supported by the Comandos platform: C++; Eiffel; and the Comandos Object-Oriented Language. This report is published as Chapter 4. of The Comandos Distributed Application Platform Cahill, V., Balter, R., Harris, N. and Rousset de Pina, X. (Eds.), Springer-Verlag, Berlin, 1993. Document No TCD-CS-93-34 The provision of programming language support was a key aspect of the Comandos project. Two different approaches to the provision of programming language support were considered in the framework of the project: the use of existing languages, and the provision of a new language environment. The first approach allows the facilities of the existing programming environment to be exploited and existing code to be reused where appropriate. However, because of the constraints imposed by using (or modifying) existing compilers, some features of the Comandos model cannot be fully integrated within an existing language. In contrast, defining ...

The relationship between framework design and language constructs are discussed for two reasons: firstly, designing frameworks requires the ability to give the framework designer precise control over aspects of the framework extensions; secondly, the framework constraints should be specified such that they are statically checkable. Four existing language constructs are discussed: generalized block structure, generalized inheritance, generalized virtuality, and singular objects. It is discussed how these language constructs give precise means for controlling the framework extensions in statically checkable ways. 1 Frameworks and Languages A framework encapsulates a reusable, stable design and provides hooks for extending and varying this design and is planned for reuse. Its whole reason for existence is to be reused in different applications. A framework realizes a coherent software architecture, consisting of classes and objects with well-defined structural and behavioral properties ...

ASPECT ORIENTED PROGRAMMING (AOP) is a new technology for separation of concerns. AOP techniques make it possible to modularise cross-cutting aspects of a system: those that would otherwise be scattered throughout the code because the concerns they address are not aligned with the conceptual decomposition of the system. Without AOP techniques, such aspects are hard to encapsulate. The essential components of AOP are exemplified by its flagship language ASPECTJ-- an aspect oriented extension to JAVA-- these are: member introduction: a way for one class to add members to other classes, parent introduction: a way for classes to influence the inheritance of other classes, join points: places where behaviour can be added to existing code, advice: a way to modify behaviour at join points; aspects: encapsulated units combining join point and behaviour specifications together with their associated state; and weaving a method of incorporating these units into programs.