Question

I’m attempting to use abstract typing to simplify and clarify type handling, but I keep encountering seemingly non-sensical errors like these:

trait Delta[A] {
  def apply(c: A)
}

abstract class ValueHolder {

  type Value
  type Event <: Delta[ValueHolder]

  def update(next: Value): Event = new UpdateEvent(next)
  // type mismatch;  found   : UpdateEvent[ValueHolder]
  // required: ValueHolder.this.Event
}

class UpdateEvent[C <: ValueHolder](next: C#Value) extends Delta[C] {

  def apply(c: C) = c.update(next)
  // type mismatch;  found   :
  // UpdateEvent.this.next.type (with underlying type C#Value)
  // required: c.Value
}

1. Doesn’t Delta[C], where C <: ValueHolder, thus conform to Event <: Delta[ValueHolder]?

2. Likewise, given that c is a C, isn’t c.Value a C#Value?

I can use a cast to remove the second error, but that defeats the point of using types.

I tried to incorporate the answer suggested in [this related question][1]…

class UpdateEvent[C <: ValueHolder, V <: C#Value](next: V) extends Delta[C] {

… which, sadly, fails to alleviate either problem (although it requires a few more type parameters when called from update()).

Help???

---

Update: Unfortunately, the example I gave above was a bit oversimplified. I’m trying to propagate changes to classes having the same method signatures (though possibly different type parameters), which thus act as “views” of the original.

For example, imagine you could run this:

(ListBuffer[Int]:_).map(_.toString)

… and then have the resulting ListBuffer[String] updated every time the original is. (Without just running “map” over and over, for reasons I can’t explain briefly.) As with this tiny example, others define the traits being implemented, meaning I can’t change the method signatures to work around the problem.

(NB: I also can’t get rid of type Event because there’s a variable (not illustrated here) containing all the listeners who receive each Event — and the type of that should be refined by subclasses to allow more specific kinds of listeners for each.)

Anyway, after much time pondering the not-very-explanatory Scala Reference manual (the information is all there, but it assumes you know a lot already), I finally figured out how to constrain UpdateEvent so that C and C#Value correspond:

class UpdateEvent[V, C <: ValueHolder { type Value = V }](
  next: V) extends Delta[C] { ... }

This fixes both compilation errors and preserves the existing approach. But I’m marking Peter’s answer (below) as correct (giving him the reputation points) because I so very much appreciate his spending time on it. Thanks, Peter, and best to you.

Answer 1

Doesn’t Delta[C], where C <: ValueHolder, thus conform to Event <: Delta[ValueHolder]?

I am not entirely sure about this, so take the following as a theory. The compiler could only ensure that Delta[C], where C <: ValueHolder, is-a Delta[ValueHolder], if the type parameter of Delta were covariant (that is, Delta[+A]). But currently it is invariant, so the above is not true. Neither can the compiler know whether a Delta[C] is an Event: Event is an abstract type, i.e. a placeholder for some type to be defined later, which will be a subtype of Delta[ValueHolder]. However, it can be defined as any such subclass, not just UpdateEvent! So I may define a ValueHolder subclass with an Event type of OtherEvent, which is thus not an UpdateEvent. If the compiler allowed this, the eventual result would be a runtime error.

Likewise, given that c is a C, isn’t c.Value a C#Value?

Indeed it is. But look at the error message:

  // type mismatch;  found   :
  // UpdateEvent.this.next.type (with underlying type C#Value)
  // required: c.Value

That is, the compiler needs a type of c.Value and it got a C#Value instead. And C#Value is not a c.Value – the former is the more general type!

Part of a potential solution may be to make update parameterized with a bound type parameter C <: ValueHolder, and then use C#Value as the parameter type, instead of ValueHolder#Value. This would eliminate the second error. A solution for the first problem may be to replace the return type of Event with Delta[C]. Thus the following compiles:

trait Delta[A] {
  def apply(c: A): Delta[A]
}

abstract class ValueHolder {

  type Value

  def update[C <: ValueHolder](next: C#Value): Delta[C] = new UpdateEvent(next)
}

class UpdateEvent[C <: ValueHolder](next: C#Value) extends Delta[C] {

  override def apply(c: C) = c.update(next)
}

Notes:

• in this scheme, Event is actually no more used, so it can be completely removed
• I defined the return type of Delta.apply as Delta[A], to comply with the type actually returned by UpdateEvent.apply
• due to this, the type parameter A could only be invariant here, because A now stands both in a covariant (as a method return type) and a contravariant (as a method parameter) position within Delta.

Hope this helps – I am not sure what you are trying to achieve though, so I may have slaughtered your original idea with these modifications 🙂