3 ms·
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 eq
by joostdevries 9y ago
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 9y ago> 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?
- virtualwhys 9y agoType 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.
- lkitching 9y agoIt'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 9y agoNice, that makes it more clear. Thanks!