It has been recognized in several works that a slice of behavior affecting a set of collaborating classes is a better unit of reuse than a single class. Different techniques and language extensions have been suggested to express such slices in programming languages. We propose delegation layers, an approach that scales the OO mechanisms for single objects, such as delegation, late binding, and subtype polymorphism, to sets of collaborating objects. Technically, delegation layers combine and generalize delegation and virtual class concepts. Due to their runtime semantics, delegation layers are more flexible than previous compile time approaches like mixin layers.

Object-oriented languages come with pre-defined composition mechanisms, such as inheritance, object composition, or delegation, each characterized by a certain set of composition properties, which do not themselves individually exist as abstractions at the language level. However, often non-standard composition semantics is needed, with a mixture of composition properties, which is not provided as such by any of the standard composition mechanisms. Such non-standard semantics are simulated by complicated architectures that are sensitive to requirement changes and cannot easily be adapted without invalidating existing clients. In this paper, we propose compound references, a new abstraction for object references, that allows us to provide explicit linguistic means for expressing and combining individual composition properties on-demand. The model is statically typed and allows the programmer to express a seamless spectrum of composition semantics in the interval between object composition and inheritance. The resulting programs are better understandable, due to explicitly expressed design decisions, and less sensitive to requirement changes.

this article, we propose a treatment of environments and the mechanism by which they are reified and manipulated, that addresses these concerns. The language described below (Rascal) permits environments to be reified into data structures, and data structures to be reflected into environments, but gives users great flexibility to constrain the extent and scope of these processes. We argue that the techniques and operators developed define a cohesive basis for building largescale modular systems using reflective programming techniques.

ions are introduced using notation; conditionals are written using !; application is expressed by juxtaposition of the function being applied with its arguments. Recursion is expressed using letrec . 3.1 Records Records are non-strict finite associations of labels to values. The constituent expressions in a record are evaluated relative to the record's evaluation environment. The value of a record field can be retrieved using the "." operator: if r is a record, then evaluating r:x returns the binding value of x as defined in r. We provide one other operation over records. Let r 1 and r 2 be two records and let Dom(r) be the set of names defined within record r. The join or composition of r 1 and r 2 (written (ffl r 1 r 2 )) is now defined as follows: (ffl r 1 r 2 ):x = ae r 2 :x if x 2 Dom(r2) r 1 :x otherwise 3 Besides these basic syntactic forms, we introduce various syntactic extensions (or abbreviations) throughout the paper; these extensions are best thought of as macros th...

It has been recognized in several works that a slice of behavior affecting a set of collaborating classes is a better unit of reuse than a single class. Different techniques and language extensions have been proposed to express such slices in programming languages. We present a Java language extension that builds up on mixin layers and combines and generalizes virtual class and delegation concepts. The result is a language that allows runtime composition of components and better reusability of client code.

The formal definition of any namespace device found in a programming language can be given in terms of transformations on a semantic environment. It is therefore worthwhile to consider the implications of incorporating environments as bona fide data objects in a programming system. Because of their expressive power, environments can be easily abused. Reifying an environment can entail the capture of unwanted bindings, leading to potentially severe violations of lexical abstraction and locality. Reflecting a data structure into an environment may cause useful program transformations which rely on static scoping (e.g., ff- conversion) to be no longer applicable. Proposals that have heretofore been suggested for manipulating environments as data objects, however, provide no mechanism to constrain the effect (or extent) of the reification or reflection process. In this paper, we propose a treatment of environments and the mechanism by which they are reified and manipulated that addresses ...

Object-oriented languages come with pre-defined composition mechanisms, such as inheritance, object composition, or delegation, each characterized by a certain set of composition properties, which do not themselves individually exist as abstractions at the language level. However, often non-standard composition semantics is needed, with a mixture of composition properties, which is not provided as such by any of the standard composition mechanisms. Such non-standard semantics are simulated by complicated architectures that are sensitive to requirement changes and cannot easily be adapted without invalidating existing clients.

gical predicates (like assert/retract) in that it bounds theory modification to specific goal proofing, thus preserving declarative semantics as well as allowing an efficient implementation. While contexts can be interpreted as structured objects, contextual binding policies can be used to reproduce inheritance and delegation mechanisms However, object representation can be given only in structural terms (i.e. a context is always denoted by listing all its composing units). In order to allow referring contexts through explicit names, CSM contextual logic programming model [2] provides the notion of context as first-class object, and introduces a new relation between atoms (context identifiers) and structured theories. Moreover, locality and encapsulation principles are basically unattended. In fact, part of a state instance has always to be represented in terms of calculated answer, thus delegating its handling and recording to the instance client. Then, a different way to coherently

... ein Paradigma der Softwareentwicklung, welches das Erstellen von Software durch das Zusammensetzen modular vorliegender Merkmale ermöglicht. Mit aspektorientierter Programmierung (Aspect-Oriented Programming – AOP) wird das Ziel verfolgt Eigenschaften von Software, die über große Teile des Programmcodes verteilt sind, zu kapseln und von anderen Eigenschaften zu trennen. Beiden Ansätzen ist eines gemein: Die Separate Behandlung der Merkmale einer Software (Separation of Concerns). Dennoch sind die Ansätze in ihrer Umsetzung von Grund auf verschieden und haben sowohl Vor- als auch Nachteile. In dieser Arbeit wird FeatureC++ vorgestellt, eine Umsetzung der FOP für C++, die Elemente der AOP integriert. Es werden zwei Dinge gezeigt: (1) Es ist eine Anwendung der AOP auf merkmalsorientierten Quelltext möglich, und (2) die FOP lässt sich auf Aspekte erweitern. Dabei wird festgestellt, dass beide Ansätze von dieser Kombination profitieren.

A dynamic proxy object is a typed proxy, created at runtime, conforming to a type specified by the application. Such an object can be used wherever an expression of the type it was created for is expected, yet reifies all invocations performed on it. This simple but powerful concept has been introduced into Java at version 1.3 (and has later also appeared in the.NET platform). A dynamic proxy is created for a set of interfaces as an instance of a class, generated automatically on the fly without support from the Java compiler or virtual machine, implementing those interfaces. Unfortunately, dynamic proxies are only available “for interfaces”. The case of creating dynamic proxies for a set of types including a class type, due to the increased complexity, has not been considered, meaning that it is currently not possible to create a dynamic proxy mimicking an instance of a class. We present a pragmatic approach to supporting dynamic proxies “for classes”, building on the existing solution to dynamic proxies for interfaces. We discuss the costs of such an extension, in terms of safety, security, and performance, and illustrate its usefulness through a novel abstraction for decoupled remote interaction, unifying (implicit future) remote method invocations and (type-based) publish/subscribe.