Why is an anonymous class created when mixing in a trait?

Question

scala> class A
defined class A

scala> trait B
defined trait B

Creating an object of class A gives us:

scala> new A
res4: A = A@11ea3fc

But creating an object of class A with trait B mixed in gives us:

scala> new A with B
res3: A with B = $anon$1@172aa3f

Here we have an anonymous class (hinted by anon). Why ?

Is this because the type A with B is regarded as a new type (and which was not defined with an identifier before) ?

Answer 1

This is not only because A with B has to be regarded as a new type. For the Scala type system, it does not directly matter if there exists a class corresponding to A with B. An anonymous class is generated because it has to contain bridge methods for all methods in the traits that have been mixed in.

The reason that an anonymous class is created is that the object must have implementations of all the methods from A and all the methods from B. On the JVM bytecode level, this would warrant inheriting multiple classes, and the multiple inheritance model is not supported on the JVM.

To simulate multiple inheritance (or mixin composition, however you wish to call it), Scala does the following things when you create a trait:

1. If the trait T has no method implementations, it creates an interface which defines all the methods in the trait.

2. If the trait T has method implementations, it additionally creates a class T$class which has a static method for each of the concrete methods in T. This static method has the same body as its corresponding method in T, but its signature is changed to include the this parameter. If T had:

   def foo(x: Int) = x
   

then T$class will have:

<static> def foo($this: T, x: Int) = x

The class obtained by mixin composition of some class A and some trait T will then have a special bridge method generated which forwards the call to the static method which contains the body. This way, the body of the method is not duplicated in every class which mixes in T. This is why the anonymous class has to be created - it has to have bridge methods defined for each method in T.

Here's an example. When you create a new class by doing mixin composition, e.g. call new A with T:

class A {
  def bar = println("!")
}

trait T {
  def foo(x: Int) = x
}

new A with T

the compiler will rewrite it roughly to something like this:

class A {
  def bar = println("!")
}

<interface> T {
  def foo(x: Int): Int
}

class T$class {
  <static> def foo($this: T, x: Int) = x
}

class $anon extends A <implements> T {
  // notice that `bar` is inherited, but `foo` is not
  <bridge> def foo(x: Int) = T$class.foo(this, x)
}
new $anon

Notice that the compiler could actually rewrite the callsites to foo to call the static methods directly from the callsite, rather than through a bridge method. The reason why it's not done that way is because then it would not support subtyping polymorphism anymore.