Scala: Abstract Types and Mixins - scala

Question

Say I have two classes with the same identifier for a parameterized type
trait A {
type O
def f(a: Int, os: Seq[O]): Int
}
trait B {
type O
def g(a: Int, o: O): Int = { h1(o) + h2(a) }
def h1(o: O): Int
def h2(a: Int): Int = {a/2}
}
I would like to create a child class that will "marry" the two
trait C extends A with B {
def f(a: Int, os: Seq[O]): Int = {
os.map{ o => g(a, o) }.sum
}
}
Finally, I create an implementation for C
class D extends C {
type O = Int
def h1(o: O): Int = {5 * o}
}
At writing of C I don't yet know what type O is -- however, I'd like to constrain A.O == B.O such that it "makes sense" to use B.g in an implementation of A.f. I tried implementing this and it surprisingly seemed like Scala assumed there was only ever one type O
val d = new D
println(d.f(1, Seq(1,2,3)))
To me this seems incorrect -- why should A.O and B.O agree?
EDIT
I'd also like to note that If you were to instead put constraints on O like so,
case class Z()
case class Z1() extends Z
case class Z2() extends Z1
trait A {
type O <: Z
}
trait B {
type O >: Z2
}
class D extends C {
type O = Z1
Compilation will fail. However, if you put this instead,
trait A {
type O <: Z
}
trait B {
type O <: Z1
}
class D extends C {
type O = Z2
Compilation succeeds and everything runs fine.

Answer 1

I think Scala always "marries" the members -- both type and value members -- of traits when both are mixed in:
trait A { type T = Int }
trait B { type T = String }
object C extends A with B
gives
overriding type T in trait A, which equals Int;
type T in trait B, which equals String needs `override' modifier
(it's how Scala deals with the multiple inheritance issue -- no matter how many times an identifier is mixed in, it only exists once).

Answer 2

You second example fails because Scala needs a bit of help in establishing the type bounds in C. I suppose maybe it should be smart enough to figure it out on its own, but someone more versed in type theory would have to explain why or why not. This definition for C should work:
trait C extends A with B {
type O >: Z2 <: Z // restrict O's type so it's valid for both A and B
}
Scala's handling of abstract types is similar to its handling of abstract methods. Methods of the same name (and signature) that are pulled in from multiple traits are overridden together. Take the classic counter-example, derived from an example given in Ye Olde C++ Programming Language.
trait Cowboy {
/** Shoot something */
def draw
}
trait Window {
/** Draw something */
def draw
}
class CowboyWindow {
/** Probably best to draw something on the screen, then shoot it */
def draw {
// ...
}
}
In the same way that it assumes that there's only one type O in your code, it assumes there's only one method draw in this code. In this instance, this assumption is problematic, since you could end up shooting yourself in the foot.
As you discovered in your example, usually this assumption works out for the best (think about multiple interfaces declaring a close() method). But if this assumption is problematic for some class, as it is for CowboyWindow, you can replace inheritance with composition to work around it.