在这个解决方案中，mixin包含有这样的观点：确定在名称不一致的情况中要调用哪个方法。
“mixin类”是个有趣的概念，也常常是个很好的设计选择。
另外，你可以使用混合类的绝对名作为参数的前缀名。这可以去除不明确的情况，例如。
根据特定上下文的要求，可以用不同的父类实例化mixin。
在Jam中，使用mixin类def内的声明来声明父类所需的方法，类似于：inherited。
之所以使用mixin这个名称，是因为这样的类可以以各种方式与其它类混合在一起。
mixin的每个实例化被编译成独立的Java类；各个副本上不存在任何共享的字节码。
而且请注意，类型检查器甚至不能检查是否每个mixin实例化都会产生有效的超级构造函数调用。
通过使用泛型类型合并mixin，我们能解决其它mixin公式的许多关键限制。
原因是：mixin和泛型类都能被认为是将现有类映射到新类的函数。
然而它仍是一个非常遗憾的约束，因为它限制了适合于转换成mixin的类集合。
可能的显示阻塞（show-stopper）将“this”作为参数从mixin内部传递给方法或构造器，这是被禁止的！
但是合并mixin以作为泛型类型系统的一部分很吸引人，几乎可以说魅力无穷。
在mixin中不能声明构造器，它只适用于mixin实例化。
混合类型更像修饰器，向节点提供额外的特征。
在最简单的情况下，只需将mix：versionable混合类型添加到任何节点，就可以执行版本管理。
如果在mixin实例化中没有指定任何构造器，那么就假定是缺省的不带参数的（zeroary）构造器。
mixin可被视为将现有类映射成新子类的函数。
子类化你的核心内容，为你的领域类混入任意模块，这正好能正常工作。
当mixin被明确表述为泛型类时，意外覆盖的问题特别讨厌。
其原因是：在某些其它上下文中，mixin的参数可能用类型参数界限实例化了。
将mixin明确表述为泛型类，我们就始终有父类的句柄，它是该类继承的类型参数。
但是，将mixin明确表述为泛型类型时有其它一些明显的困难。