Does a Mixin By Definition Allow Storing Data in Mixin-Level Instance Variables?

Question

Several implementations of mixins (e.g. Ruby mixin, Scala trait) include support for storing data (e.g. variables, properties) between method calls in instance variables. There was a bit of debate in this question about whether or not a Java virtual extension method qualified as a mixin because they cannot store data in this way; all variables are inputted and outputted within the scope of the method call and cannot be stored in an instance variable. Essentially, there was debate about what a "mixin" by definition is and whether or not implementations in Ruby and whatnot go beyond the commonly recognized definition of the programming concept.

Unfortunately, the definition of a mixin seem rather vague in this regard. For instance, Wikipedia says the following:

With mixins the class definition defines only the attributes and parameters associated with that class; methods are left to be defined elsewhere, as in Flavors and CLOS, and are organized in "generic functions". These generic functions are functions that are defined in multiple cases (methods) by type dispatch and method combinations.

The above says that a mixin defines attributes, but doesn't cite sources that might clarify this. However, every other definition simply fails to mention whether or not mixins allow storing data or if they are limited to methods. To further add confusion, Wikipedia earlier describes mixins as an interface with implemented methods, but interfaces can't store instance variables. I tried to find out how it was defined in Flavors, which was the first programming language to use something called "mixins", but I couldn't find enough information online about it.

So can a mixin by definition allow storing data? Or is this something that is ambiguous and is left up to the programming language to decide?

Answer 1

The paper Mixin-based Inheritance by Bracha and Cook [PDF] shows that inheritance as found in the languages Smalltalk, Beta and CLOS can be reinterpreted as specializations of mixin inheritance.

The main point here is that inheritance can be viewed as a linear application of abstract deltas to a base class, e.g.

class Foo {
  int num = 42;
  int doStuff() { return num; }
}

class Bar extends Foo {
  void otherStuff() { return; }
}

– here we could interpret both classes as deltas: The Foo mixin adds a doStuff method and a num member, while Bar adds otherStuff. However, mixins can't be instantiated on their own (are abstract). Expressed this way, with mixin composition via the ⊕ operator:

mixin MFoo {
  int num = 42;
  int doStuff() { return num; }
}

class Foo = MFoo ⊕ Object;

mixin MBar {
  void otherStuff() { return; }
}

class Bar = MBar ⊕ Foo
          = MBar ⊕ (MFoo ⊕ Object)

Classical single inheritance is a specialization of mixins where each delta can only be applied to a single superclass (MBar can only be applied to Foo, but not also to Baz).

If single class inheritance can be viewed as a specialization of mixins, then mixins allow the inheritance of data! However, a specific specialization of mixins need not require this. Both class inheritance and interfaces are specializations of mixins.

Java's extension methods do not allow storage of state, thus Java 8 interfaces are not able to model class inheritance. Therefore, these interfaces are not mixins in the sense of Bracha and Cook. They do however offer mixin-like functionality in that they allow to inherit functionality from multiple types, thus providing a weak kind of multiple inheritance.

---

Two points remain worth mentioning, although they are tangential to my argument:

First, nowadays traits are all the rage. This is an extension of mixins that doesn't require linear composition. All newer mixin-like systems actually implement traits or at least call them such.

Second, the design rationale for extension methods in Java 8 is not primarily to add mixins, traits, or multiple inheritance but rather to add the ability to retroactively extend existing interfaces to use new methods. It is intended that these extension methods are overridden by implementing classes. Importantly, this allows to update the Collection interface to include methods like the higher-order function map without breaking code that implemented Collection during Java 7 times and thus has no implementation for map.