Stateful traits

  • Authors:

  • Alexandre Bergel;Stéphane Ducasse;Oscar Nierstrasz;Roel Wuyts

  • Affiliations:

  • DSG, Trinity College Dublin, Ireland;Language and Software Evolution, LISTIC, Université de Savoie;University of Bern;Lab for Software Composition and Decomposition, Université Libre de Bruxelles

  • Venue:
  • ISC'06 Proceedings of the 14th international conference on Advances in smalltalk
  • Year:
  • 2006

Quantified Score

Hi-index 0.00

Visualization

Abstract

Traits offer a fine-grained mechanism to compose classes from reusable components while avoiding problems of fragility brought by multiple inheritance and mixins. Traits as originally proposed are stateless, that is, they contain only methods, but no instance variables. State can only be accessed within traits by accessors, which become required methods of the trait. Although this approach works reasonably well in practice, it means that many traits, viewed as software components, are artificially incomplete, and classes that use such traits may contain significant amounts of boilerplate glue code. Although these limitations are largely mitigated by proper tool support, we seek a cleaner solution that supports stateful traits. The key difficulty is how to handle conflicts that arise when composed traits contribute instance variables whose names clash. We present a solution that is faithful to the guiding principle of stateless traits: the client retains control of the composition. Stateful traits consist of a minimal extension to stateless traits in which instance variables are purely local to the scope of a trait, unless they are explicitly made accessible by the composing client of a trait. Naming conflicts are avoided, and variables of disjoint traits can be explicitly merged by clients. We discuss and compare two implementation strategies, and briefly present a case study in which stateful traits have been used to refactor the trait-based version of the Smalltalk collection hierarchy.