Results 1 - 10
of
62
On the Notion of Inheritance
- ACM Computing Surveys
, 1996
"... One of the most intriguing—and at the same time most problematic—notions in object-oriented programming is inheritance. Inheritance is commonly regarded as the feature that distinguishes object-oriented programming from other modern programming paradigms, but researchers rarely agree on its meaning ..."
Abstract
-
Cited by 106 (0 self)
- Add to MetaCart
One of the most intriguing—and at the same time most problematic—notions in object-oriented programming is inheritance. Inheritance is commonly regarded as the feature that distinguishes object-oriented programming from other modern programming paradigms, but researchers rarely agree on its meaning and usage.
A Nominal Theory of Objects with Dependent Types
- In Proc. ECOOP’03, Springer LNCS
, 2002
"... We design and study νObj, a calculus and dependent type system for objects and classes which can have types as members. Type members can be aliases, abstract types, or new types. The type system can model the essential concepts of Java's inner classes as well as virtual types and family polymorph ..."
Abstract
-
Cited by 84 (14 self)
- Add to MetaCart
We design and study νObj, a calculus and dependent type system for objects and classes which can have types as members. Type members can be aliases, abstract types, or new types. The type system can model the essential concepts of Java's inner classes as well as virtual types and family polymorphism found in BETA or gbeta. It can also model most concepts of SML-style module systems, including sharing constraints and higher-order functors, but excluding applicative functors. The type system can thus...
A Programmer's Reduction Semantics for Classes and Mixins
, 1999
"... While class-based object-oriented programming languages provide a flexible mechanism for re-using and managing related pieces of code, they typically lack linguistic facilities for specifying a uniform extension of many classes with one set of fields and methods. As a result, programmers are unable ..."
Abstract
-
Cited by 81 (8 self)
- Add to MetaCart
While class-based object-oriented programming languages provide a flexible mechanism for re-using and managing related pieces of code, they typically lack linguistic facilities for specifying a uniform extension of many classes with one set of fields and methods. As a result, programmers are unable to express certain abstractions over classes. In this paper we develop a model of class-to-class functions that we refer to as mixins. A mixin function maps a class to an extended class by adding or overriding fields and methods. Programming with mixins is similar to programming with single inheritance classes, but mixins more directly encourage programming to interfaces. The paper develops these ideas within the context of Java. The results are 1. an intuitive model of an essential Java subset; 2. an extension that explains and models mixins; and 3. type soundness theorems for these languages. 1 Organizing Programs with Functions and Classes Object-oriented programming languages offer classes, inheritance, and overriding to parameterize over program pieces for management purposes and re-use. Functional programming languages provide various flavors of functional abstractions for the same purpose. The latter model was developed from a well-known, highly developed mathematical theory. The former grew in response to the need to manage large programs and to re-use as many components as possible. Each form of parameterization is useful for certain situations. With higherorder functions, a programmer can easily define many functions that share a similar core but differ in a few details. As many language designers and programmers readily acknowledge, however, the functional approach to parameterization is best used in situations with a relatively small number of parameters. When ...
Jam - A Smooth Extension of Java with Mixins
- In ECOOP 2000, number 1850 in LNCS
, 1999
"... In this paper we present Jam, an extension of the Java language supporting mixins, that is, parametric heir classes. A mixin declaration in Jam is similar to a Java heir class declaration, except that it does not extend a fixed parent class, but simply specifies the set of fields and methods a gener ..."
Abstract
-
Cited by 50 (10 self)
- Add to MetaCart
In this paper we present Jam, an extension of the Java language supporting mixins, that is, parametric heir classes. A mixin declaration in Jam is similar to a Java heir class declaration, except that it does not extend a fixed parent class, but simply specifies the set of fields and methods a generic parent should provide. In this way, the same mixin can be instantiated on many parent classes, producing different heirs, thus avoiding code duplication and largely improving modularity and reuse. Moreover, as happens for classes and interfaces, mixin names are reference types, and all the classes obtained instantiating the same mixin are considered subtypes of the corresponding type, hence can be handled in a uniform way through the common interface. This possibility allows a programming style where different ingredients are "mixed" together in defining a class; this paradigm is somehow similar to that based on multiple inheritance, but avoids the associated complications. The ...
Classbox/J: Controlling the scope of change in Java
- In Proceedings of Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA’05
, 2005
"... www.iam.unibe.ch/∼scg Unanticipated changes to complex software systems can introduce anomalies such as duplicated code, suboptimal inheritance relationships and a proliferation of run-time downcasts. Refactoring to eliminate these anomalies may not be an option, at least in certain stages of softwa ..."
Abstract
-
Cited by 49 (7 self)
- Add to MetaCart
www.iam.unibe.ch/∼scg Unanticipated changes to complex software systems can introduce anomalies such as duplicated code, suboptimal inheritance relationships and a proliferation of run-time downcasts. Refactoring to eliminate these anomalies may not be an option, at least in certain stages of software evolution. Classboxes are modules that restrict the visibility of changes to selected clients only, thereby offering more freedom in the way unanticipated changes may be implemented, and thus reducing the need for convoluted design anomalies. In this paper we demonstrate how classboxes can be implemented in statically-typed languages like Java. We also present an extended case study of Swing, a Java GUI package built on top of AWT, and we document the ensuing anomalies that Swing introduces. We show how Classbox/J, a prototype implementation of classboxes for Java, is used to provide a cleaner implementation of Swing using local refinement rather than subclassing.
A Core Calculus of Classes and Mixins
, 1999
"... We develop an imperative calculus that provides a formal model for both single and mixin inheritance. By introducing classes and mixins as the basic object-oriented constructs in a -calculus with records and references, we obtain a system with an intuitive operational semantics. New ..."
Abstract
-
Cited by 49 (15 self)
- Add to MetaCart
We develop an imperative calculus that provides a formal model for both single and mixin inheritance. By introducing classes and mixins as the basic object-oriented constructs in a -calculus with records and references, we obtain a system with an intuitive operational semantics. New
Privacy via Subsumption
- Information and Computation
, 1998
"... We describe an object calculus that allows both extension of objects and full width subtyping (hiding arbitrary components). In contrast to other proposals, the types of our calculus do not mention "missing " methods. To avoid type unsoundness, the calculus mediates all interaction with objects via ..."
Abstract
-
Cited by 44 (2 self)
- Add to MetaCart
We describe an object calculus that allows both extension of objects and full width subtyping (hiding arbitrary components). In contrast to other proposals, the types of our calculus do not mention "missing " methods. To avoid type unsoundness, the calculus mediates all interaction with objects via "dictionaries" that resemble the method dispatch tables in conventional implementations. Private fields and methods can be modeled and enforced by scoping restrictions: forgetting a field or method through subsumption makes it private. We prove that the type system is sound, give a variant which allows covariant self types, and give some examples of the expressiveness of the calculus. 1 Introduction One of the most important principles of software engineering is information hiding: the ability to build and enforce data or procedural abstractions in order to make programs readable and maintainable. Most object-oriented programming languages provide direct support for information hiding. Clas...
Mediators: Easing the Design and Evolution of Integrated Systems
, 1994
"... People benefit from tightly integrated systems that can be designed, realized and evolved affordably. Unfortunately, common software design methods do not easily accommodate requirements for tightly integrated systems. Indeed, when used to meet such requirements, common methods tend to yield unnec ..."
Abstract
-
Cited by 37 (14 self)
- Add to MetaCart
People benefit from tightly integrated systems that can be designed, realized and evolved affordably. Unfortunately, common software design methods do not easily accommodate requirements for tightly integrated systems. Indeed, when used to meet such requirements, common methods tend to yield unnecessarily complex structures that complicate design and realization and that inhibit subsequent evolution. After substantiating this claim, I present the mediator method as a solution. This method combines behavioral entity-relationship (ER) modeling for design with a mediator approach to implementation. The mediator method is better than common methods for designing, realizing, and evolving many integrated systems. I support this claim both by rational argument from simplifying models and by careful...
Dynamic Object Evolution without Name Collisions
- In Proceedings ECOOP ’97, LNCS 1241
, 1997
"... . Support for modular evolution of objects is required in many application areas. However, existing mechanisms for incremental behavior composition either do not support evolving objects at all, or do not satisfactorily solve the encapsulation and name collision problems associated with them. In thi ..."
Abstract
-
Cited by 36 (5 self)
- Add to MetaCart
. Support for modular evolution of objects is required in many application areas. However, existing mechanisms for incremental behavior composition either do not support evolving objects at all, or do not satisfactorily solve the encapsulation and name collision problems associated with them. In this paper, a new approach to behavior composition in a class-based environment is presented. It is based on the encapsulated object model of class-based inheritance, but introduces an additional abstraction layer between objects and classes. By being responsible for the compositional aspects of the behavior of objects, this layer provides support for the evolution of behavior while at the same time solving the name conflicts that may occur. A formal description of the approach is provided and its feasibility is demonstrated by implementing it as a metalevel extension of Smalltalk-80. 1 Introduction In several object-oriented application areas, support for dynamic and incremental evolution of ...
A Theory of Mixin Modules: Basic and Derived Operators
- Mathematical Structures in Computer Science
, 1996
"... Mixins are modules in which some components are deferred , i.e. their definition has to be provided by another module. Moreover, differently from parameterized modules (like ML functors), mixin modules can be mutually dependent and their composition supports redefinition of components (overriding). ..."
Abstract
-
Cited by 35 (12 self)
- Add to MetaCart
Mixins are modules in which some components are deferred , i.e. their definition has to be provided by another module. Moreover, differently from parameterized modules (like ML functors), mixin modules can be mutually dependent and their composition supports redefinition of components (overriding). In this paper, we present a formal model of mixins and their basic composition operators. These operators can be viewed as a kernel language with clean semantics in which to express more complex operators of existing modular languages, including variants of inheritance in object oriented programming. Our formal model is given in an "institution independent" way, i.e. is parameterized by the semantic framework modeling the underlying core language. Introduction In object oriented languages, the definition of an heir class H from a parent class P takes usually the form H = extend P by M , where M denotes a collection of definitions of components (typically methods) which are either new, or re...

