I\'m designing a class hierarchy, which consists of a base class along with several traits. The base class provides default implementations of several methods, and the trai
This isn't possible.
But you can use implicitly
and Scala's type inference to make this as painless as possible.
trait MyTrait {
protected[this] implicit def e: ClassName
}
and then
class MyClass extends MyTrait {
protected[this] val e = implicitly // or def
}
Succinct, and doesn't even require writing the type in the extending class.
As it looks like this isn't possible, I went for the option of declaring the implicit val
on the base class' constructor. As pointed out in the question this isn't ideal, but it satisfies the compiler and, pragmatically, isn't too much of a burden in my particular case.
If anyone has a better solution though, I'd be happy to hear and accept it.
Actually, I've wanted this quite often before, but just came up with this idea. You can translate
trait T(implicit impl: ClassName) {
def foo = ... // using impl here
}
to [EDITED: original version didn't provide access to implicit for other methods]
trait T {
// no need to ever use it outside T
protected case class ClassNameW(implicit val wrapped: ClassName)
// normally defined by caller as val implWrap = ClassNameW
protected val implWrap: ClassNameW
// will have to repeat this when you extend T and need access to the implicit
import implWrap.wrapped
def foo = ... // using wrapped here
}
I ran into this problem a few times, and indeed it's a bit annoying, but not too much. Abstract members and parameters are usually two alternative ways of doing the same thing, with their advantages and disadvantages; for traits having an abstract member is not too inconveniente, because you need anyway another class to implement the trait.*
Therefore, you should simply have an abstract value declaration in the trait, so that implementing classes have to supply an implicit for you. See the following example - which compiles correctly, and shows two ways of implementing the given trait:
trait Base[T] {
val numT: Ordering[T]
}
/* Here we use a context bound, thus cannot specify the name of the implicit
* and must define the field explicitly.
*/
class Der1[T: Ordering] extends Base[T] {
val numT = implicitly[Ordering[T]]
//Type inference cannot figure out the type parameter of implicitly in the previous line
}
/* Here we specify an implicit parameter, but add val, so that it automatically
* implements the abstract value of the superclass.
*/
class Der2[T](implicit val numT: Ordering[T]) extends Base[T]
The basic idea I show is also present in Knut Arne Vedaa's answer, but I tried to make a more compelling and convenient example, dropping usage of unneeded features.
*This is not the reason why trait cannot accept parameters - I don't know it. I'm just arguing that the limitation is acceptable in this case.
You could do it like this:
abstract class C
trait A { this: C =>
val i: Int
}
implicit val n = 3
val a = new C with A {
val i = implicitly[Int]
}
But I'm not sure if there's any point in it - you could just as well reference the implicit value explicitly.
I guess what you want is to get rid of the implementation of i
in the instantiation, but as you say yourself, the core of the problem is that traits doesn't take constructor parameters - whether they would be implicit or not doesn't matter.
A possible solution for this problem would be to add a new feature to the already valid syntax:
trait A {
implicit val i: Int
}
where i
would be implemented by the compiler if an implicit was in scope.