Results 1 - 10
of
29
Dynamically Composable Collaborations with Delegation Layers
- In Proc. of ECOOP 2002, LNCS
, 2002
"... 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 ..."
Abstract
-
Cited by 59 (4 self)
- Add to MetaCart
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.
Language constructs for context-oriented programming
- In Proceedings of the Dynamic Languages Symposium
, 2005
"... ContextL is an extension to the Common Lisp Object System that allows for Context-oriented Programming. It provides means to associate partial class and method definitions with layers and to activate and deactivate such layers in the control flow of a running program. When a layer is activated, the ..."
Abstract
-
Cited by 46 (11 self)
- Add to MetaCart
ContextL is an extension to the Common Lisp Object System that allows for Context-oriented Programming. It provides means to associate partial class and method definitions with layers and to activate and deactivate such layers in the control flow of a running program. When a layer is activated, the partial definitions become part of the program until this layer is deactivated. This has the effect that the behavior of a program can be modified according to the context of its use without the need to mention such context dependencies in the affected base program. We illustrate these ideas by providing different UI views on the same object while, at the same time, keeping the conceptual simplicity of objectoriented programming that objects know by themselves how to behave, in our case how to display themselves. These seemingly contradictory goals can be achieved by separating class definitions into distinct layers instead of factoring out the display code into different classes.
Type-safe prototype-based component evolution
- Proceedings ECOOP 2002, volume 2374 of LNCS
, 2002
"... Component-based programming is currently carried out using mainstream object-oriented languages. These languages have to be used in a highly disciplined way to guarantee flexible component composition and extensibility. This paper investigates abstractions for component-oriented programming on the ..."
Abstract
-
Cited by 30 (6 self)
- Add to MetaCart
Component-based programming is currently carried out using mainstream object-oriented languages. These languages have to be used in a highly disciplined way to guarantee flexible component composition and extensibility. This paper investigates abstractions for component-oriented programming on the programming language level. We propose a simple prototype-based model for first-class components on top of a class-based object-oriented language. The model is formalized as an extension of Featherweight Java. Our calculus includes a minimal set of primitives to dynamically build, extend, and compose software components, while supporting features like explicit context dependencies, late composition, unanticipated component extensibility, and strong encapsulation. We present a type system for our calculus that ensures type-safe component definition, composition, and evolution.
Object-Oriented Composition Untangled
- In Proceedings OOPSLA ’01
, 2001
"... 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 ..."
Abstract
-
Cited by 18 (4 self)
- Add to MetaCart
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.
Evolving Software with Extensible Modules
, 2002
"... We present the programming language Keris, an extension of Java with explicit support for software evolution. Keris introduces extensible modules as the basic building blocks for software. Modules are composed hierarchically revealing explicitly the architecture of systems. A distinct feature of the ..."
Abstract
-
Cited by 18 (2 self)
- Add to MetaCart
We present the programming language Keris, an extension of Java with explicit support for software evolution. Keris introduces extensible modules as the basic building blocks for software. Modules are composed hierarchically revealing explicitly the architecture of systems. A distinct feature of the module design is that modules do not get linked manually. Instead, the wiring of modules gets infered. The module assembly and refinement mechanism of Keris is not restricted to the unanticipated extensibility of atomic modules. It also allows to extend fully linked systems by replacing selected submodules with compatible versions without needing to re-link the full system. Extensibility is type-safe and non-invasive; i.e. the extension of a module preserves the original version and does not require access to source code.
Efficient layer activation for switching context-dependent behavior
- In JMLC ’06: Proceedings of the Joint Modular Languages Conference
, 2006
"... Abstract. Today’s programming platforms do not provide sufficient constructs that allow a program’s behavior to depend on the context in which it is executing. This paper presents the design and implementation of programming language extensions that explicitly support our vision of Context-oriented ..."
Abstract
-
Cited by 11 (3 self)
- Add to MetaCart
Abstract. Today’s programming platforms do not provide sufficient constructs that allow a program’s behavior to depend on the context in which it is executing. This paper presents the design and implementation of programming language extensions that explicitly support our vision of Context-oriented Programming. In this model, programs can be partitioned into layers that can be dynamically activated and deactivated depending on their execution context. Layers are sets of partial program definitions that can be composed in any order. Context-oriented Programming encourages rich, dynamic modifications of program behavior at runtime, requiring an efficient implementation. We present a dynamic representation of layers that yields competitive performance characteristics for both layer activation/deactivation and overall program execution. We illustrate the performance of our implementation by providing an alternative solution for one of the prominent examples of aspect-oriented programming. 1
Towards Unanticipated Runtime Adaptation of Java Applications
"... Modifying an application usually means to stop the application, apply the changes, and start the application again. That means, the application is not available for at least a short time period. This is not acceptable for highly available applications. One reasonable approach which faces the problem ..."
Abstract
-
Cited by 7 (6 self)
- Add to MetaCart
Modifying an application usually means to stop the application, apply the changes, and start the application again. That means, the application is not available for at least a short time period. This is not acceptable for highly available applications. One reasonable approach which faces the problem of unavailability is to change highly available applications at runtime. To allow extensive runtime adaptation the application must be enabled for unanticipated changes even of already executed program parts. This is due to the fact that it is not predictable what changes become necessary and when they have to be applied. Since Java is commonly used for developing highly available applications, we discuss its shortcomings and opportunities regarding unanticipated runtime adaptation. We present an approach based on Java HotSwap and object wrapping which overcomes the identified shortcomings and evaluate it in a case study. 1.
Stand-alone messages: A step towards component-oriented programming languages
- Proceedings of the Joint Modular Languages Conference, volume 1897 of Lecture Notes in Computer Science
, 2000
"... Abstract. We are concerned with the design of programming languages that support the paradigm of component-oriented programming. Languages based on the accepted idea of combining modular and objectoriented concepts fail to provide adequate support. We argue that messages should be separated from met ..."
Abstract
-
Cited by 6 (5 self)
- Add to MetaCart
Abstract. We are concerned with the design of programming languages that support the paradigm of component-oriented programming. Languages based on the accepted idea of combining modular and objectoriented concepts fail to provide adequate support. We argue that messages should be separated from methods to address this shortcoming. We introduce the concept of stand-alone messages, give examples for its utility, and compare it to related approaches and language constructs. Besides leading to interesting insights on the interaction of modular and object-oriented concepts, we believe that stand-alone messages also provide a useful basis for further research on component-oriented programming languages. 1
Evolution of collective object behavior in presence of simultaneous client-specific view
- In Proceedings of the 9th international Conference on Object-Oriented Information OOIS’03, volume 2817 of LNCS
, 2003
"... Abstract. When different clients, each with their own individual customization requirements, use the same system simultaneously, the system must dynamically adapt its behavior on a per client basis. Each non-trivial adaptation of the system’s behavior will very likely crosscut the implementation of ..."
Abstract
-
Cited by 5 (1 self)
- Add to MetaCart
Abstract. When different clients, each with their own individual customization requirements, use the same system simultaneously, the system must dynamically adapt its behavior on a per client basis. Each non-trivial adaptation of the system’s behavior will very likely crosscut the implementation of multiple objects. In this paper we present an extension to the Java programming language that supports the dynamic evolution of collective object behavior in the presence of simultaneous client-specific views. In accordance with the separation of concerns and locality principles, client-specific customization of collective object behavior is organized as layers of mixin-like wrappers. Each layer of wrappers incrementally adds behavior and state to a group of core objects without modifying their respective implementations. Hence, collective object behavior can evolve in an additive and non-invasive way. The extension that we propose provides language constructs for defining, encapsulating and selecting behavioral refinements, and runtime support for transparently integrating them on demand. 1

