Results 1 - 10
of
14
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.
Classboxes: Controlling visibility of class extensions
- Computer Languages, Systems and Structures
, 2005
"... A class extension is a method that is defined in a module, but whose class is defined elsewhere. Class extensions offer a convenient way to incrementally modify existing classes when subclassing is inappropriate. Unfortunately existing approaches suffer from various limitations. Either class extensi ..."
Abstract
-
Cited by 34 (11 self)
- Add to MetaCart
A class extension is a method that is defined in a module, but whose class is defined elsewhere. Class extensions offer a convenient way to incrementally modify existing classes when subclassing is inappropriate. Unfortunately existing approaches suffer from various limitations. Either class extensions have a global impact, with possibly negative effects for unexpected clients, or they have a purely local impact, with negative results for collaborating clients. Furthermore, conflicting class extensions are either disallowed, or resolved by linearization, with consequent negative effects. To solve these problems we present classboxes, a module system for object-oriented languages that provides for method addition and replacement. Moreover, the changes made by a classbox are only visible to that classbox (or classboxes that import it), a feature we call local rebinding. To validate the model we have implemented it in the Squeak Smalltalk environment, and performed benchmarks.
Evolvable Pattern Implementations Need Generic Aspects
- Proc. of ECOOP'2004 Workshop on Reflection, AOP and Meta-Data for Software Evolution at ECOOP 2004
, 2004
"... Design patterns are a standard means to create large software systems. However, with standard object-oriented techniques, typical implementations of such patterns are not themselves reusable software entities. Evolution of a program into a ‘patterned ’ form (also known as ‘refactoring to patterns’) ..."
Abstract
-
Cited by 23 (2 self)
- Add to MetaCart
Design patterns are a standard means to create large software systems. However, with standard object-oriented techniques, typical implementations of such patterns are not themselves reusable software entities. Evolution of a program into a ‘patterned ’ form (also known as ‘refactoring to patterns’) and subsequent evolution of a ‘patterned ’ design is largely left to the programmer. Due to their ability to encapsulate elements that crosscut different modules, aspect languages have the potential to change this situation. For many interesting patterns, a large part of the process of refactoring to patterns can already be implemented modularly in aspects. Still, existing aspect languages can only express a small number of typical patterns implementations in a generally reusable way. In many cases, evolution of an application that uses one pattern variant into one that uses another one cannot be achieved at all. In others, it requires duplicating parts of the aspect implementation, thus creating scattered code in the aspects and hindering their further evolution. In this paper, we argue that aspect languages need to provide genericity in order to support reusable pattern implementations. We sketch the main features of the generic aspect language LogicAJ, and show how it supports software evolution. In particular, we demonstrate how LogicAJ enables evolution of a non-patterned implementation to a patterned one and easy transition from one patterned implementation to another. 1.
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.
Translation polymorphism in Object Teams
, 2004
"... In this paper we present the mechanisms of lifting and lowering which have been incorporated into recent programing languages. In these languages, lifting and lowering are key features in the integration of static, class based inheritance and instance based composition with delegation. We present th ..."
Abstract
-
Cited by 7 (3 self)
- Add to MetaCart
In this paper we present the mechanisms of lifting and lowering which have been incorporated into recent programing languages. In these languages, lifting and lowering are key features in the integration of static, class based inheritance and instance based composition with delegation. We present the embedding of these concepts into our model Object Teams. We elaborate the details of rules and constraints at the type level, which give to the approach the capability of non-invasively integrating modules with different inheritance structures. These rules setup a new kind of substitutability called translation polymorphism. We show how translation polymorphism integrates with subtype polymorphism. By generalizing over the presented techniques we conclude that lifting opens a second dimension for dispatch in object-oriented languages, be supplementing method dispatch with instance dispatch. 1
Object Confinement in Object Teams - Reconciling Encapsulation and Flexible Integration
"... Aspect-oriented software development (AOSD) may introduce invisible links and control flows in an application, which are perceived as an obstacle to understandability, predictability and safety. The resulting trade-off between exibly structuring crosscutting concerns and rigorously pursuing program ..."
Abstract
-
Cited by 4 (0 self)
- Add to MetaCart
Aspect-oriented software development (AOSD) may introduce invisible links and control flows in an application, which are perceived as an obstacle to understandability, predictability and safety. The resulting trade-off between exibly structuring crosscutting concerns and rigorously pursuing program safety impedes the usefulness of AOSD for many fields of application. The model of Object Teams combines ideas from many programming languages providing greater expressiveness than each of its predecessors. In this position paper it is argued, that Object Teams also provide strong concepts for encapsulation, which help for modular reasoning about aspect-oriented programs developed in this model.
Supporting Extension of Components with new Paradigms
- In OOPSLA 2000 workshop on Advanced Separation of Concerns
, 2000
"... Component-based applications require more than simply components. They extend and configure components and "glue" them together to construct an application. Requirements like extensibility and configurability become mission critical. Traditional solutions in this area rely on software design pattern ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Component-based applications require more than simply components. They extend and configure components and "glue" them together to construct an application. Requirements like extensibility and configurability become mission critical. Traditional solutions in this area rely on software design patterns and have been successfully employed for a large inhouse project at Siemens. This paper examines the influence of AspectJ and Hyper/J in this field and compares them to conventional solutions. The result indicates that especially AspectJ has major limitations, which we think is due to missing theoretical foundation in the areas of type theory and integration with existing approaches. Introduction Large applications at Siemens and other companies are more and more based on components. On first glance, components look like perfect reusable assets. However, even if they are domain specific, they remain generalized software solutions and therefore need to be adapted to deployment-specific nee...
Infrastructure Support for Engineering Complex Object-Oriented Systems for Evolution
, 2001
"... With conventional object technology, systematic engineering of object-oriented systems for evolution is difficult. At best, one can build applications that are evolvable with respect to a few anticipated variation points. However, unanticipated evolution, which accounts for most changes of long-l ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
With conventional object technology, systematic engineering of object-oriented systems for evolution is difficult. At best, one can build applications that are evolvable with respect to a few anticipated variation points. However, unanticipated evolution, which accounts for most changes of long-lived software, is not adequately supported. Therefore, infrastructures that support unanticipated software adaptation (USA) and its run-time variant, unanticipated software system reconfiguration (USSR) are a basic prerequisite for effective software evolution. This paper discusses the limitations of existing object technology and sketches an infrastructure for USA / USSR that extends the Java platform by two generic adaptation techniques: object-based inheritance and transmigration of object identity. The TAILOR infrastructure reduces the costs of developing, maintaining and deploying software due to less down-times and increased reuse of existing software when faced with unanticipated change. 1
MASPEGHI 2004 - Mechanisms for Specialization, Generalization and Inheritance
- In ECOOP Workshops
, 2004
"... MASPEGHI 2004 is the third edition of the MASPEGHI workshop. This year the organizers of both the ECOOP 2002 Inheritance Workshop and MASPEGHI 2003 came together to enlarge the scope of the workshop and to address new challenges. We succeeded in gathering a diverse group of researchers and pract ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
MASPEGHI 2004 is the third edition of the MASPEGHI workshop. This year the organizers of both the ECOOP 2002 Inheritance Workshop and MASPEGHI 2003 came together to enlarge the scope of the workshop and to address new challenges. We succeeded in gathering a diverse group of researchers and practitioners interested in mechanisms for managing specialization and generalization of programming language components. The workshop contained a series of presentations with discussions as well as group work, and the interplay between the more than 22 highly skilled and inspiring people from many di#erent communities gave rise to fruitful discussions and the potential for continued collaboration.
Simulating multiple inheritance and generics in Java
, 1999
"... This paper presents Java language from an object-oriented software construction perspective. It explains the implications of banning generics and multiple inheritance of classes, and explores the patterns and the idioms used by the Java designers and programmers to redeem their bene#ts. The paper al ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
This paper presents Java language from an object-oriented software construction perspective. It explains the implications of banning generics and multiple inheritance of classes, and explores the patterns and the idioms used by the Java designers and programmers to redeem their bene#ts. The paper also discusses an alternative to multiple inheritance, as incorporated in Lava, which extends Java with constructs for type-safe automatic forwarding.

