Team RMoD

Overall Objectives
Scientific Foundations
New Results
Contracts and Grants with Industry
Other Grants and Activities

Section: Scientific Foundations

Language Constructs for Modular Design

While the previous axis focuses on how to help remodularizing existing software, this second research axis aims at providing new language constructs to build more flexible and recomposable software. We will build on our work on traits [106] , [60] and classboxes [44] but also start to work on new areas such as security in dynamic languages. We will work on the following points: (1) Traits: behavioral units and (2) Modularization as a support for security.

Traits-based program reuse

Context and Problems. 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 designed a new composition mechanism called Traits [106] , [60] . Traits are pure units of behavior that can be composed to form classes or other traits. The trait composition mechanism is an alternative to multiple or mixin inheritance in which the composer has full control over the trait composition. The result enables more reuse than single inheritance without introducing the drawbacks of multiple or mixin inheritance. Several extensions of the model have been proposed [56] , [99] , [45] , [61] and several type systems where defined [65] , [107] , [101] , [80] .

Traits are reusable building blocks that can be explicitly composed to share methods across unrelated class hierarchies. In their original form, traits do not contain state and cannot express visibility control for methods. Two extensions, stateful traits and freezable traits, have been proposed to overcome these limitations. However, these extensions are complex and not simple to implement.

Research Agenda: Towards a pure trait language. We plan distinct actions: (1) a large application of traits, (2) assessment of the existing trait-models and (3) bootstrapping a pure trait language.

Reconciling Dynamic Languages and Security

Context and Problems. More and more applications require dynamic behavior such as modification of their own execution (often implemented using reflective features [75] ). For example, F-script allows one to script Cocoa Mac-OS X applications and Lua is used in Adobe Photoshop. Now in addition more and more applications are updated on the fly, potentially loading untrusted code or simply broken code. Bytecode checking and static code verification are used to enable security, however such approaches do not really work in presence of dynamic languages and reflective features. Therefore there is a tension between a need for flexibility and for security —here, by security we mean a mix between confidentiality and integrity.

Research Agenda: A secure dynamic and reflective language. To solve this tension, we will work on Sure , a language where security is provided by construction: as an example, if the language does not offer field access and its reflective facilities are controlled, then the possibility to access and modify private data is controlled. In this context, layering and modularizing the meta-level [48] , as well as controlling the access to reflective features [51] , [52] are important challenges. We plan to:

An open question is whether, instead of providing restricted interfaces, we could use traits to grant additional behavior to specific instances: without trait application the instances would only exhibit default public behavior, but with additional traits applied, the instances would get extra behavior. We will develop Sure , a modular extension of the reflective kernel of Smalltalk (since it is one the language offering the largest set of reflective features such as pointer swapping, class changing, class definition...) [102] .


Logo Inria