On Traits and Types in a Java-like Setting

Abstract

Both single and multiple class-based inheritance are often inappropriate as a reuse mechanism, because classes play two competing roles. Namely, a class is both a generator of instances and a unit of reuse. Traits are composable pure units of behavior reuse, consisting only of methods, that have been proposed as an add-on to single class-based inheritance in order to improve reuse. However, adopting traits as an add-on to traditional class-based inheritance is not enough: classes, besides their primary role of generators of instances, still play the competing role of units of reuse. Therefore, a style of programming oriented to reuse is not enforced by the language, but left to the programmer's skills. Traits have been originally proposed in the setting of dynamically typed language. When static typing is also taken into account, the role of unit of reuse and the role of type are competing, too.We argue that, in order to support the development of reusable program components, object oriented programming languages should be designed according to the principle that each software structuring construct must have exactly one role. We propose a realignment of the class-based object-oriented paradigm by presenting programming language features that separate completely the declarations of object type, behavior and generator. We illustrate our proposal through a core calculus and prove the soundness of the type system w.r.t. the operational semantics.

Magda: A New Language for Modularity

“…Initially they were introduced in a untyped setting as an extension of Smalltalk [22,46]. Later on they were studied also in typed (thus often restricted) settings [47,44,11,6]. One of the design goals of this approach was to overcome problems with mixins mentioned above.…”

A Calculus for Boxes and Traits in a Java-Like Setting

“…In the language considered in this paper a trait consists of methods, of required methods, which parametrize the behavior, and of required fields that can be directly accessed in the body of the methods, along the lines of [2,4]. Traits are building blocks to compose classes and other, more complex, traits.…”

“…The most important rule is (V-ANNOTATION), which guarantees that Constraint-based Ownership Typing for WBTJ. The constraint-based ownership type system for WBTJ can be understood as a refinement of the type system (for a Javalike calculus with traits) proposed in [4], to keep box and ownership annotations into account. The type-checking of each trait definition, in isolation from the classes or traits that use it, is realized by collecting, for each method definition in the trait, the constraints on the use of this within the method body.…”

“…Traits were introduced and implemented in the dynamically-typed class-based language SQUEAK/SMALLTALK [11] 1 . Various formulations of traits in a JAVA-like setting can be found in the literature (see, e.g., [25,17,3,23,4,14]). Also two recent languages, SCALA and FORTRESS, incorporate forms of the trait construct.…”

Simulation of the cdmm-p paradigm-driven meta-modeling process

“…It is a graph-like structure, so the disadvantages of the concept of configuration mentioned above are limited as a result. It is worth noticing here that there are two kinds of contexts: the static context, which helps to create static structures with well-defined responsibility (meta-models) [26,23,24,25]; and the dynamic context, which helps to enrich functionalities of the static structure [3,2,4]. This article is focused on the static contexts only.…”