Mixin Ordering

Mixins are a feature of Scala that allow for more complex class composition than what you see in Java (essentially multiple inheritance with better rules to avoid ambiguity). In Scala, "classes" that you mix in are called traits. They let you do some nice things such as mix in utilities that a lot of classes use, e.g. a Logging trait which has a method that lets you print to the console with the class name.

	trait Logging {
	def log(message: String) {
	println("[" + getClass().getCanonicalName() + "] " + message)
	}
	}
	class Foo extends Logging {
	log("Hello")
	log("World!")
	}

view raw Logging.scala hosted with ❤ by GitHub

Creating an instance of the Foo class prints the following:

	[blog.scala.mixin.Foo] Hello
	[blog.scala.mixin.Foo] World!

view raw logging-output.txt hosted with ❤ by GitHub

While in this case we could have just made Logging a class and had Foo extend it, when you have a real class hierarchy and Foo has a real superclass, it's not easy to have this logging functionality in a single place. Allowing us to mix in the Logging trait into any class gives us a much better way to reuse code.

As with many features of Scala, mixins are both powerful and potentially dangerous. In particular, the ordering of mixins has an effect on the behavior of the program beyond the standard "later traits override methods of earlier traits" contract.  Consider the following example which is intended to print out a fact about a meter.

	trait ConversionConstants {
	val CentimetersInAMeter = 100
	}
	trait PrintFact {
	println(getFact)
	def getFact: String
	}
	object PrintFactAboutAMeter extends PrintFact with ConversionConstants {
	def getFact = "There are " + CentimetersInAMeter + " centimeters in a meter."
	def main(args: Array[String]) {}
	}

view raw PrintFactAboutAMeter.scala hosted with ❤ by GitHub

It turns out that the output of this program is not what you would expect, but rather

There are 0 centimeters in a meter.

view raw meter-output.txt hosted with ❤ by GitHub

So why is this? Because this example is relatively simple, it's pretty easy to see that the getFact method is being called when the PrintFact trait is initialized, which you might guess happens before the ConversionConstants trait is initialized (and you'd be right). So the value read is 0 instead of the expected 100. It should also be clear that reversing the order of the traits will actually fix the problem since ConversionConstants doesn't have a (indirect) dependency on PrintFact. Moreover, omitting the PrintFact trait and putting the print statement in the body of PrintFactAboutAMeter also fixes the problem because the class constructor is called after all of the traits are initialized.

While the particular example described here might seem contrived, I ran into this problem recently while working on a real project, and it led to a very strange debugging session. So it is important to be careful when using mixins, specifically when doing anything in the initialization of a trait (as well as in a superclass constructor), because you might inadvertently add a dependency going in the wrong direction along the mixin ordering. This is a bit reminiscent of circular dependencies in static initializers in Java.