DeepFJig — Modular composition of nested classes.

Abstract

We present a new language design which smoothly integrates modular composition and nesting of Java-like classes. That is, inheritance has been replaced by an expressive set of composition operators, inspired by Bracha's Jigsaw framework, and these operators allow to manipulate (e.g., rename or duplicate) a nested class at any level of depth. Typing is nominal as characteristic of Java-like languages, so types are paths of the form outer n .C 1 . . . . .C k which, depending on the class (node) where they occur, denote another node in the nesting tree. However, paths denoting the same class are not equivalent, since they behave differently w.r.t. composition operators.The resulting language, called DEEPFJIG, obtains a great expressive power, allowing, e.g., to solve the expression problem, encode basic AOP mechanisms, and bring some refactoring techniques at the language level, while keeping a very simple semantics and type system which represent a natural extension for, say, a Java programmer.

Separating Use and Reuse to Improve Both

“…where method ma is imported from A. This concept is natural for a Java programmer, but was not supported in previous work [8,16]. Those works require all dependencies in code literals to be explicitly declared, so that the code literal is self-contained; in this way it can be typed in isolation before flattening.…”

“…inherited). We are aware of at least 3 concrete independently designed research languages following this methodology: TraitRecordJ [6], Package Templates [26] and DeepFJig [16].Approach: In this paper, we design 42 µ , a new language, where we improve use and reuse and support the This type and family polymorphism by distinguishing code designed for use from code designed for reuse. In this way 42 µ synthesise the 3 approaches above, and improves them with abstract state operations: a new elegant way to handle state composition in trait based languages.Knowledge and Grounding: Using case studies, we show that 42 µ 's model of traits with abstract state operations is more usable and compact than prior work.…”

“…DJ and TR would instead require explicitly declaring an abstract ma method: 1 B=Use ta, { method int ma() //not required by us 2 method int mb(){return this.ma();} } In 42 µ , methods are directly accessible from ta, exactly as in the Java equivalent 1 class B extends A{ int mb(){return this.ma();} }where method ma is imported from A. This concept is natural for a Java programmer, but was not supported in previous work [8,16]. Those works require all dependencies in code literals to be explicitly declared, so that the code literal is self-contained; in this way it can be typed in isolation before flattening.…”

DeepFJig

“…For instance, in the example in Section 1.4, The other rules model composition operators. Auxiliary functions are informally defined in the text and formally defined in [11].…”

“…In Section 2 we provide the formal semantics, and in Section 3 we summarize the contribution of the paper and discuss related work. Formal definitions of auxiliary functions used in Section 2, type system and soundness results can be found in the extended version 1 [11]. A preliminary version of this paper is [10].…”