[joostdevries]

Being able to take an instance Person and make it be an Employee without changes to the Person class definitely sounds like ad hoc polymorphism. In Scala the equivalent of Haskells type classes is implicits though. Not traits. I do wonder if this 'extension interface implementation' feature would support the same inferencing that type classes in Haskell and implicits in Scala do. So that might be a difference.

[daxfohl]

> In Scala the equivalent of Haskells type classes is implicits though. Not traits.

Really? I'm not an expert but everything I've read until this implies the opposite. Besides, C# already has implicit conversions, and they're different from type classes in that they convert, not extend. Once an int is implicitly converted to a double, it's always a double from within the function that converted it, not just "representing" a double. So strictly less powerful than polymorphism. My understanding that type classes were the way out of that, and traits were Scala's equivalent. Is that not correct?

[lkitching]

It's implicit arguments, not implicit conversions that enable type classes in Scala, although the class is usually represented by a trait e.g.

    trait Show[T] { def show(v : T): String }
    implicit object ShowInt extends Show[Int] {
	def show(i: Int) = i.toString
    }
    def showLine[T](v : T)(implicit show: Show[T]): Unit = {
        println(show.show(v))
    }

[daxfohl]

Nice, that makes it more clear. Thanks!

[virtualwhys]

Type classes in Scala typically entail a mix of features: implicits, traits, and higher kinded types.

Assume you're thinking about C#'s extension methods, which in Scala are achieved via implicit classes.