Recent years have seen a shift in perception of the nature of HCI and interactive systems. As interface work has increasingly become a focus of attention for the social sciences, we have expanded our appreciation of the importance of issues such as work practice, adaptation, and evolution in interactive systems. The reorientation in our view of interactive systems has been accompanied by a call for a new model of design centered around user needs and participation. This article argues that a new process of design is not enough and that the new view necessitates a similar reorientation in the structure of the systems we build. It outlines some requirements for systems that support a deeper conception of interaction and argues that the traditional system design techniques are not suited to creating such systems. Finally, using examples from ongoing work in the design of an open toolkit for collaborative applications, it illustrates how the principles of computational reflection and metaobject protocols can lead us toward a new model based on open abstraction that holds great promise in addressing these issues.

Reflective programming languages are those where users' programs are allowed to customize in an organized way the behavior of the language to their own needs. For ten years now, most of the work on reflection revolved around the definition and the implementation of metaobject protocols which express this organization. No methodologies have been proposed for reflective programming per se. This paper proposes a first one aiming at the design of composable metaobjects. Given two independently developed reflective customizations, this methodology proposes principles to be observed in their design such that they can be composed using standard base-level aggregation or specialization. While this paper focuses on a simple MOP and illustrates the methodology on specific examples, this methodology can be generalized to other languages with different MOPs. For instance, we discuss how to adapt it to Clos. Keywords Composition, Aggregation, Specialization, Reflection, MetaObject Protocol, Metho...

Reflection is a wide-ranging concept that has been studied independently in many different areas of science in general, and computer science in particular. Even in the sub-area of programming languages, it has been applied to different paradigms, especially the logic, functional and objectoriented ones. Partly because of different past influences, but also because researchers in these communities scarcely talk to each others, concepts have evolved separately, sometimes to the point where it is hard for people in one community to recognize similarities in the work of others, not to speak about cross-fertilization among them. In this paper, we propose a synthesis covering mainly the application of computation reflection to programming languages. We compare the different approaches and try to identify similar concepts hidden behind different names or constructs. We also point out the different emphasis that has been given to different concepts in each of them. We do not claim neither comp...

. A method definition can be viewed as a logical assertion. Whenever we declare a method as the implementation of an operation, we assert that if the operation is invoked on objects of the appropriate types then the method body will satisfy the specification of the operation. This view of methods as assertions is simple but general. Among its applications are: methods defined on interfaces as well as on classes; an elementary type system for objects that handles multi-methods; and a mechanism for method dispatch based on the desired output type as well as on the types of arguments. Further, these applications are compatible with traditional execution models and implementation techniques. Logical reasoning about methods plays a role at compile time, then gets out of the way. 1 Introduction An object is commonly characterized as a collection of data together with associated procedures, called methods. Each method implements an operation on the object; an operation may have other impleme...

The need to "open" object languages in order to make them more able to fit new situations appears as a major issue. More and more, objects will be persistent and mobile and will have to get adapted to the evolution of their original pattern. In the context of software engineering class languages, these ideas mean that the basic mechanisms (classes, inheritance and client-supplier links) need more flexibility. According to that, we propose a general model which allows some customization of class language semantics. This model provides a reflective and structured framework for the encapsulation of first level object semantics into three main types of meta-programmable components ("classes", "links" and "languages") which role and potential interest are presented in this paper.

Reflection is a design principle that allows a system to have a representation of itself in the manner that makes it easy to adapt the system to a changing environment. It has now matured to the point where it is used to address real-world problems in various areas. This principle has been also identified as a pattern of software architecture (PoSA) [1]. This paper presents a non-software examples of the Reflection pattern. We present a simple and household example and an example in the immune system. We believe our work helps understand the intent, structure and consequences of the Reflection pattern.

Contents 1 Introduction 1 1.1 The Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . . 3 2 Aspect-Oriented Programming 4 2.1 Classi#cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 The Code Tangling Phenomenon . . . . . . . . . . . . . . . . . . 5 2.3 Aspects and Aspect Languages . . . . . . . . . . . . . . . . . . . 10 2.4 Weaving Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5 Summary and Outlook . . . . . . . . . . . . . . . . . . . . . . . . 14 3 The Process Synchronization Aspect 15 3.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.1 Smalltalk's Process Model . . . . . . . . . . . . . . . . . . 15 3.1.2 Processes in the Server . . . . . . . . . . . . . . . . . . . . 16 3.1.3 Techniques for Synchronizing Processes . . . . . . . . . . 17 3.1.4 Process Synchronization in the S

The online version of this article can be found at: