Behavioral reflection is a powerful approach for adapting the behavior of running applications. In this paper we present and motivate partial behavioral reflection, an approach to more efficient and flexible behavioral reflection. We expose the spatial and temporal dimensions of such reflection, and propose a model of partial behavioral reflection based on the notion of hooksets. In the context of Java, we describe a reflective architecture offering appropriate interfaces for static and dynamic configuration of partial behavioral reflection at various levels, as well as Reflex, an open reflective extension for Java implementing this architecture. Reflex is the first extension that fully supports partial behavioral reflection in a portable manner, and that seamlessly integrates load-time and runtime behavioral reflection. The paper shows preliminary benchmarks and examples supporting the approach. The examples, dealing with the observer pattern and asynchronous communication via transparent futures, also show the interest of partial behavioral reflection as a tool for open dynamic Aspect-Oriented Programming.

Design patterns ease the designing, understanding, and re-engineering of software. Achieving a well-designed piece of software requires a deep understanding and a good practice of design patterns. Understanding existing software relies on the ability to identify architectural forms resulting from the implementation of design patterns. Maintaining software involves spotting places that can be improved by using better design decisions, like those advocated by design patterns. Nevertheless, there is a lack of tools automatizing the use of design patterns to achieve well-designed pieces of software, to identify recurrent architectural forms, and to maintain software. We present a set of tools and techniques to help OO software practitioners design, understand, and re-engineer a piece of software using design-patterns. A first prototype tool, PATTERNS-BOX, provides assistance in designing the architecture of a new piece of software, while a second prototype tool, PTIDEJ, identifies design patterns used in an existing one. These tools, in combination, support maintenance by highlighting defects in an existing design, and by suggesting and applying corrections based on widely-accepted design pattern solutions.

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.

Prototype-based languages are currently proposed as a substitute to class-based languages for a higher flexibility in manipulating objects.These languages are all based on a similar set of basic principles: object-centered representation, dynamic addition (deletion) of slots, cloning and message delegation.But they all differ in the precise interpretation of these principles and nobody has yet considered the semantic issues raised by their combination.In this paper, we propose a new taxonomy of prototypebased languages, enhancing the Treaty of Orlando by now discussing issues associated with the different semantics of the identified prototype-based languages.From this taxonomy, we extract a constructive proposal for the design of a new prototype-based language.This proposal is the chief result of this paper; it suggests one set of primitives which is regarded as the best to provide a clean, useful and coherent prototype-based computational model.We finally describe an implementation of most interesting language alternatives in the form of a Smalltalk-platform.This platform establishes an operational semantics for the basic primitives andmore interesting -validates our previous taxonomy by implementing it as a class hierarchy.Obviously, this platform has been used to relate in the same formalism the semantics of different languages with each others.For instance, the programming models of existing languages, such as Self, ObjectLisp and Actra's examplars, are faithfully derived as subclasses in this hierarchy.

This paper discusses the introduction of explicit metaclasses á la ObjVlisp into the Smalltalk-80 language. The rigidity of Smalltalk metaclass architecture motivated this work. We decided to implement the ObjVlisp model into the standard Smalltalk-80 system. The resulting combination defines the Classtalk platform. This platform provides a full-size environment to experiment with class-oriented programming by combining implicit metaclasses á la Smalltalk and explicit metaclasses á la ObjVlisp. Obviously, these experiments are not limited to the Smalltalk world and will be useful to understand and practice the metaclass concept advocated by modern object-oriented languages such as ObjVlisp and CLOS.

This paper shows how an attempt at a uniform and re-flective definition resulted in an open-ended system sup-porting ObjVlisp, which we use to simulate object-oriented language extensions. We propose to unify Smalltalk classes and their terminal instances. This unification allows us to treat a class as a “first class citizen”, to give a circular definition of the first metaclass, to access to the metaclass level and finally to control the instantiation link. Because each object is an instance of another one and because a metaclass is a real class inheriting from another one, the metaclass links can be created indefinitely. This uniformity allows us to define the class variables at the metalevel thus suppressing the Smalltalk- ambiguity between class variables and instance variables: in our model the instance variables of a class are the class variables of its instances.