Yes, unfortunately this is a side-effect of how we change the Scala REPL's code
generation. Before, the REPL would create a singleton object for each line:
object Line1 {
class Foo
}
object Line2 {
import Line1.Foo
class Bar(val x: Int) extends Foo
}
And so on. We change this to:
class Line1 {
class Foo
}
object Line1 { val INSTANCE = new Line1 }
class Line2 {
import Line1.INSTANCE.Foo
class Bar(val x: Int) extends Foo
}
object Line1 { val INSTANCE = new Line2 }
Now, Foo becomes an inner class of Line1 instead of a top-level static class,
so it's bound to the Line1 instance that it belongs to, and the compiler can't
prove that the Foos you pass to meow are necessarily subclasses of
Line1.INSTANCE.Bar (as opposed to Bar in general).
Unfortunately this is kind of tricky to fix without more hacking of the Scala
interpreter. The reason we switched to these classes is to allow variable
definitions to work correctly. For example, if you do
var x = Console.readLine()
The original Scala interpreter would do
object Line1 {
var x = Console.readLine()
}
This is bad because it would mean that on *every* worker node that uses x, we'd
be trying to call Console.readLine.
Matei
On Sep 13, 2013, at 9:04 AM, Jey Kottalam <[email protected]> wrote:
> If I execute the following sequence of inputs in both "scala" and
> "spark-shell" I see different results:
>
> class Foo
> class Bar(val x: Int) extends Foo
> val a = Seq[Bar](new Bar(10), new Bar(20), new Bar(30))
> def meow(x: Seq[Foo]) = x(0)
> meow(a)
>
>
> Under scala I see the following as expected:
>
> scala> meow(a)
> res0: Foo = Bar@7f020a15
>
>
> Under spark-shell I see this:
>
> scala> meow(a)
> <console>:19: error: type mismatch;
> found : Seq[this.Bar]
> required: Seq[this.Foo]
> meow(a)
>
>
> It appears that somehow Seq[T] is no longer covariant? I'm sure this
> is just some kind of Scala ignorance on my part, but any hints would
> be appreciated.
>
> Thanks,
> -Jey
