Extensible objects without labels

  • Authors:

  • Christopher A. Stone

  • Affiliations:

  • Harvey Mudd College, Claremont, CA

  • Venue:
  • ACM Transactions on Programming Languages and Systems (TOPLAS)
  • Year:
  • 2004

Quantified Score

Hi-index 0.00

Visualization

Abstract

Typed object calculi that permit adding new methods to existing objects must address the problem of name clashes: what happens if a new method is added to an object already having one with the same name but a different type? Most systems statically forbid such clashes by restricting the allowable subtypings. In contrast, by reconsidering the runtime meaning of object extension, the object calculus studied in the author's previous work with Jon Riecke allowed any object to be soundly extended with any method of any name, with unrestricted width subtyping. That language permitted a simple encoding of classes as object-generators. Because of width subtyping, subclasses could be typechecked and compiled with little knowledge of the class hierarchy and without any information about superclasses' private components; this made derived classes more robust to changes in the implementations of base classes. However, the system was not well suited for encoding mixins or by-name subtyping of objects.This article addresses those deficiencies by presenting the Calculus of Objects and Indices (COI), a lower-level typed object calculus in which extensible objects are more analogous to tuples than to records. An object is simply a finite sequence of unnamed components referenced by their index in the sequence. Names are then reintroduced by allowing these indices to be first-class values (analogous to pointers to members in C++) that can be bound to variables. Since variables---unlike record labels---freely alpha-vary, difficulties caused by statically undetectable name clashes disappear.By combining COI objects with standard type-theoretic mechanisms, one can encode mixins and classes having the by-name subtyping of languages like C++ or Java but with the robustness of the object-generator encodings. Using records, more standard extensible objects with named components can also be encoded.