Featherweight Wrap Java: wrapping objects and methods.

Abstract

We present a language extension, which integrates in a Java like language a mechanism for dynamically extending object behaviors without changing their type. Our approach consists in moving the addition of new features from class (static) level to object (dynamic) level: the basic features of entities (representing their structure) are separated from the additional ones (wrapper classes whose instances represent run-time added behaviors). At run-time, these entities can be dynamically composed by instantiating wrapper objects which are attached to basic entities. Wrappers permit specializing (wrapping) methods at run-time: the method of the wrapper will be automatically executed after the method of the wrapped objects, using a delegation mechanism. Furthermore, wrapped methods can return values and values returned by the wrapped methods are transparently made available in the wrapper methods. We formalize our extension by adding the new constructs to Featherweight Java and we prove that the core language so extended (Featherweight Wrap Java) is type safe.

Software language engineers’ worst nightmare

“…Featherweight Java [33] is a minimal core calculus for Java, proposed to facilitate understanding the consequences of extensions and variations, proposed almost two decades ago. Featherweight Java has received substantial attention since then, with a definition of its denotational semantics [65], small-step operation semantics [23], type-preserving compilation [42], received proposed extensions like Generic FJ [79], Feature FJ [4], Corecursive FJ [2], Transactional FJ [70], Feath-erTrait [44], Welterweight Java [52], Middleweight Java [9], Featherweight Wrap Java [8], and perhaps others.…”

Object reuse and behavior adaptation in Java-like languages

“…We believe our solution is simpler than the approaches presented in [27] and, in general, than a wrapper solution (such as, e.g., [7,10]). Thus we can compose two instances as follows:…”

“…Incomplete objects, as a language construct, are more generalpurpose than wrappers (see, e.g., [7,10]) and, indeed, wrappers could be actually implemented through incomplete objects. Another form of wrapping of methods is the one offered by the delegates of C#, i.e., objects pointing to one method or to a set of methods, that will be executed when invoked appropriately on the delegate.…”

“…The alternative programming style, proposed by these patterns, consists in writing small software components (units of reuse), that can be composed in several ways at run time. This leads, for instance, to the use of wrappers (see, e.g., [7,10]), that are interposed between the objects and their clients in order to implement new behavior. Besides the fact that design patterns require manual programming, which is prone to errors, these composition-based solutions are limited by the underlying model of object composition and method forwarding which is intrinsic to class-based languages.…”

I-Java: An Extension of Java with Incomplete Objects and Object Composition

“…However, they differ from decorator-based solutions such as the language extension presented in [9]: incomplete objects provide a more general-purpose language construct and the wrappers of [9] could be actually implemented through incomplete objects. Another form of wrapping of methods is the one offered by the delegates of C#.…”