Inheritance is well-known and accepted as a mechanism for reuse in object-oriented languages. Unfortunately, due to the coarse granularity of inheritance, it may be difficult to decompose an application into an optimal class hierarchy that maximizes software reuse. Existing schemes based on single inheritance, multiple inheritance, or mixins, all pose numerous problems for reuse. To overcome these problems we propose traits, pure units of reuse consisting only of methods. We develop a formal model of traits that establishes how traits can be composed, either to form other traits, or to form classes. We also outline an experimental validation in which we apply traits to refactor a non-trivial application into composable units.

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.

In this paper, I examine some of reasons that “readonly ” style qualifiers have been proposed for Java, and also the principles behind the rules for these new qualifiers. I find that there is a mismatch between some of the motivating problems and the proposed solutions. Thus I urge Java designers to proceed with caution when adopting a solution to these sets of problems. 1 Proposals for “readonly ” in Java The purpose in having qualifiers such as “readonly ” on types in a programming language is so that programmers can enlist the compiler (and loader) in enforcing rules about the proper use of data.

Encapsulation in object-oriented languages has traditionally been based on static type systems. As a consequence, dynamically-typed languages have only limited support for encapsulation. This is surprising, considering that encapsulation is one of the most fundamental and important concepts behind object-oriented programming and that it is essential for writing programs that are maintainable and reliable, and that remain robust as they evolve. In this paper we describe the problems that are caused by insufficient encapsulation mechanisms and then present object-oriented encapsulation, a simple and uniform approach that solves these problems by bringing state of the art encapsulation features to dynamically typed languages. We provide a detailed discussion of our design rationales and compare them and their consequences to the encapsulation approaches used for statically typed languages. We also describe an implementation of object-oriented encapsulation in Smalltalk. Benchmarks show that extensive use of objectoriented encapsulation results in a slowdown of less than 15 per cent.

We present an overview of JTL (the Java Tools Language, pronounced “Gee-tel”), a novel language for querying JAVA [8] programs. JTL was designed to serve the development of source code software tools for JAVA, and as a small language to aid programming language extensions to JAVA. Applications include definition of pointcuts for aspect-oriented programming, fixing type constraints for generic programming, specification of encapsulation policies, definition of micro-patterns, etc. We argue that the JTL expression of each of these is systematic, concise, intuitive and general. JTL relies on a simply-typed relational database for program representation, rather than an abstract syntax tree. The underlying semantics of the language is restricted to queries formulated in First Order Predicate Logic augmented with transitive closure (FOPL *). Special effort was taken to ensure terse, yet readable expression of logical conditions. The JTL pattern public abstract class, for example, matches all abstract classes which are publicly accessible, while class { public clone(); } matches all classes in which method clone is public. To this end, JTL relies on a DATALOG-like syntax and semantics, enriched with quantifiers and pattern matching which all but entirely eliminate the need for recursive calls. JTL’s query analyzer gives special attention to the fragility of the “closed world assumption ” in examining JAVA software, and determines whether a query relies on such an assumption. The performance of the JTL interpreter is comparable to that of JQuery after it generated its database cache, and at least an order of magnitude faster when the cache has to be rebuilt.

Abstract. Motivated by the need of application-level access control in dynamically extensible systems, this work proposes a static annotation system for modeling capabilies in a Java-like programming language. Unlike previous language-based capability systems, the proposed annotation system can provably enforce capability confinement. This confinement guarantee is leveraged to model a strong form of separation of duty known as hereditary mutual suspicion. The annotation system has been fully implemented in a standard Java Virtual Machine. 1

Recently, traits have been proposed as a single inheritance backward compatible solution in which the composing entity has the control over the trait composition. Traits are fine-grained units used to compose classes, while avoiding many of the problems of multiple inheritance and mixin-based approaches. To evaluate the expressiveness of traits, some hierarchies were refactored, showing code reuse. However, such large refactorings, while valuable, may not be facing all the problems, since the hierarchies were previously expressed within single inheritance and following certain patterns. We wanted to evaluate how traits enable reuse, and what problems could be encountered when building a library using traits from scratch, taking into account that traits are units of reuse. This paper presents our work on designing a new stream library named Nile. We present the reuse that we attained using traits, and the problems we encountered.

A version of this paper has been submitted to the 2004

Abstract Secure cooperation is the problem of protecting mutually suspicious code units from one another. The notion ofcapabilities is an effective means for facilitating secure cooperation in dynamically extensible software systems, in which both trusted and untrusted code may run alongside each other. This paper proposes a lightweight, staticallyenforceable type system, Discretionary Object Confinement (DOC), for modeling capabilities with abstract interface types. The type system can be seen as a discretionary variant of confined types. Formulated at the bytecode level,the type system is enforceable at link time, by the code consumer. Type checking does not involve any iterative flow analysis, and is therefore highly efficient. A link-time type checker has been implemented for the Java platform underthe framework of Pluggable Verification Modules. The simplicity of the type system imposes only a modest increase in size to the trusted computing base. Although DOC enjoys an efficient type checking procedure, the inference ofDOC annotations from legacy code base is NP-complete. The practical implication of this negative result is discussed. 1 Introduction Secure cooperation [27, 24] is the problem of protecting mutually suspicious code units within the same executionenvironment from one another. Peer code units collaborate by sharing object references. The challenge is to allow the owner of an object reference to impose access constraints over those object references that are shared with an untrustedpeer. Secure cooperation is thus an enabling infrastructure for dynamically extensible software systems such as mobile code language environments, scriptable applications, and software systems with plug-in architectures, in which bothtrusted and untrusted code units may run alongside each other.

Abstract. Supporting read-only and side effect free execution has been the focus of a large body of work in the area of statically typed programming languages. Read-onlyness in dynamically typed languages is difficult to achieve because of the absence of a type checking phase and the support of an open-world assumption in which code can be constantly added and modified. To address this issue, we propose Dynamic Read-Only references (DRO) that provide a view on an object where this object and its object graph are protected from modification. The readonly view dynamically propagates to aggregated objects, without changing the object graph itself; it acts as a read-only view of complex data structures, without making them read-only globally. We implement dynamic read-only references by using smart object proxies that lazily propagate the read-only view, following the object graph and driven by control flow and applied them to realize side-effect free assertions. 1