Results 1 -
7 of
7
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...
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 ...
Mirrors: design principles for meta-level facilities of object-oriented programming languages
, 2004
"... We identify three design principles for reflection and metaprogramming facilities in object oriented programming languages. Encapsulation: meta-level facilities must encapsulate their implementation. Stratification: meta-level facilities must be separated from base-level functionality. Ontological c ..."
Abstract
-
Cited by 48 (3 self)
- Add to MetaCart
We identify three design principles for reflection and metaprogramming facilities in object oriented programming languages. Encapsulation: meta-level facilities must encapsulate their implementation. Stratification: meta-level facilities must be separated from base-level functionality. Ontological correspondence: the ontology of meta-level facilities should correspond to the ontology of the language they manipulate. Traditional/mainstream reflective architectures do not follow these precepts. In contrast, reflective APIs built around the concept of mirrors are characterized by adherence to these three principles. Consequently, mirror-based architectures have significant advantages with respect to distribution, deployment and general purpose metaprogramming.
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.
Pluggable reflection: Decoupling meta-interface and implementation
- In Proceedings of the 25th International Conference on Software Engineering
, 2003
"... Reflection remains a second-class citizen in current programming models, where it’s assumed to be imperative and tightly bound to its implementation. In contrast, most object-oriented APIs allow interfaces to vary independently of their implementations. Components take this separation a step further ..."
Abstract
-
Cited by 12 (4 self)
- Add to MetaCart
Reflection remains a second-class citizen in current programming models, where it’s assumed to be imperative and tightly bound to its implementation. In contrast, most object-oriented APIs allow interfaces to vary independently of their implementations. Components take this separation a step further by describing unforeseeable attributes—the key to pluggable third-party components. This paper describes how reflection can benefit from a similar evolutionary path. 1.
What Functional Programmers can Learn from the Visitor Pattern
"... This paper explores the practical potential for enhancing code reuse in functional languages by leveraging techniques and experiences from object-oriented programming. Since data types in typed functional languages do not support adding new variants, programming techniques derived from the object-or ..."
Abstract
-
Cited by 4 (0 self)
- Add to MetaCart
This paper explores the practical potential for enhancing code reuse in functional languages by leveraging techniques and experiences from object-oriented programming. Since data types in typed functional languages do not support adding new variants, programming techniques derived from the object-oriented Visitor pattern can be readily applied to recursive functions on trees in functional languages. Specifically, we demonstrate how to define recursive functions on trees in such a way that they can be extended without modification through an inheritance-like mechanism. Furthermore, we demonstrate how the extensions themselves can be made highly reusable through a mechanism akin to mixin-based inheritance, which allows an extension to be applied to any suitable recursive function. These mechanisms combine well with the usual higher-order approach to reuse in functional languages. Although general encodings of inheritance in functional languages are not novel, such encodings lead to a particularly simple and elegant presentation when limited to recursive functions on trees. Because of their simplicity, we believe that these techniques have the potential to enhance code reuse in the practice of functional programming without requiring additional tool support.
Abstract Executable Grammars in Newspeak
, 2007
"... We describe the design and implementation of a parser combinator library in Newspeak, a new language in the Smalltalk family. Parsers written using our library are remarkably similar to BNF; they are almost entirely free of solutionspace (i.e., programming language) artifacts. Our system allows the ..."
Abstract
-
Cited by 4 (0 self)
- Add to MetaCart
We describe the design and implementation of a parser combinator library in Newspeak, a new language in the Smalltalk family. Parsers written using our library are remarkably similar to BNF; they are almost entirely free of solutionspace (i.e., programming language) artifacts. Our system allows the grammar to be specified as a separate class or mixin, independent of tools that rely upon it such as parsers, syntax colorizers etc. Thus, our grammars serve as a shared executable specification for a variety of language processing tools. This motivates our use of the term executable grammar. We discuss the language features that enable these pleasing results, and, in contrast, the challenge our library poses for static type systems. 1

