Reputation: 1675
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
}
Doesn't Delta[C]
, where C <: ValueHolder
, thus conform to Event <: Delta[ValueHolder]
?
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.
Upvotes: 1
Views: 222
Reputation: 116306
Doesn't
Delta[C]
, whereC <: ValueHolder
, thus conform toEvent <: 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 aC
, isn'tc.Value
aC#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:
Event
is actually no more used, so it can be completely removedDelta.apply
as Delta[A]
, to comply with the type actually returned by UpdateEvent.apply
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 :-)
Upvotes: 2