I have been trying to get a grasp on how implicit parameters work in Scala. As far as I can tell the implicit parameter resolution goes something like this:
However, when I started playing around with this in conjunction lazy vals I got a bit of a supprise. It seems that lazy vals only ever use the last resolution rules. Here is some sample code to illustrate:
class Bar(val name:String)
object Bar { implicit def bar = new Bar("some default bar") }
class Foo {
lazy val list = initialize
def initialize(implicit f:Bar) = {
println("initialize called with Bar: '" + f.name + "' ...")
List[Int]()
}
}
trait NonDefaultBar extends Foo {
implicit def f = new Bar("mixed in implicit bar")
def mixedInInit = initialize
lazy val mixedInList = list
}
object Test {
def test = {
println("Case 1: with implicitp parameter from companion object")
val foo1 = new Foo
foo1.list
foo1.initialize
println("Case 2: with mixedin implicit parameter overriding the default one...")
val foo2 = new Foo with NonDefaultBar
foo2.mixedInList
val foo3 = new Foo with NonDefaultBar
foo3.mixedInInit
println("Case 3: with local implicit parameter overriding the default one...")
implicit def nonDefaultBar = new Bar("locally scoped implicit bar")
val foo4 = new Foo
foo4.list
foo4.initialize
}
}
Calling Test.test
gives the following output:
Case 1: with implicitp parameter from companion object
initialize called with Bar: 'some default bar' ...
initialize called with Bar: 'some default bar' ...
Case 2: with mixedin implicit parameter overriding the default one...
initialize called with Bar: 'some default bar' ...
initialize called with Bar: 'mixed in implicit bar'...
Case 3: with local implicit parameter overriding the default one...
initialize called with Bar: 'some default bar' ...
initialize called with Bar: 'locally scoped implicit bar' ...
Why does the compiler not catch that there is a implict Bar mixed in when calling mixedInList in Case 2. In Case 3 it also misses the locally defined implicit Bar when accessing the list.
Are there any ways to use implicit parameters with lazy vals that does not use the implicit defined in the companion object?
Scala provides a nice language feature called lazy val that defers the initialization of a variable. The lazy initialization pattern is common in Java programs. Though it seems tempting, the concrete implementation of lazy val has some subtle issues.
Implicit parameters are the parameters that are passed to a function with implicit keyword in Scala, which means the values will be taken from the context in which they are called.
In Scala, objects and values are treated mostly the same. An implicit object can be thought of as a value which is found in the process of looking up an implicit of its type.
Scala 2.10 introduced a new feature called implicit classes. An implicit class is a class marked with the implicit keyword. This keyword makes the class's primary constructor available for implicit conversions when the class is in scope. Implicit classes were proposed in SIP-13.
A lazy val is most easily understood as a "memoized (no-arg) def". Like a def, a lazy val is not evaluated until it is invoked. But the result is saved so that subsequent invocations return the saved value. The memoized result takes up space in your data structure, like a val.
That is because there is no other implicit Bar
, when the compiler compiles the Foo class. The decompiled code in Java look like this:
public class Foo
implements ScalaObject
{
private List<Object> list;
public volatile int bitmap$0;
public List<Object> list()
{
if (
(this.bitmap$0 & 0x1) == 0);
synchronized (this)
{
if (
(this.bitmap$0 & 0x1) == 0) {
this.list = initialize(Bar..MODULE$.bar()); this.bitmap$0 |= 1; } return this.list;
}
}
public List<Object> initialize(Bar f) { Predef..MODULE$.println(new StringBuilder().append("initialize called with Bar: '").append(f.name()).append("' ...").toString());
return Nil..MODULE$;
}
}
The lazy val
is just a method that checks if the variable is already set and either returns it, or sets it and then returns it. So your mixin is not taken into account at all. If you want that, you have to take care of the initialization yourself.
Although scala does not support lazy vals with implicit parameters, you can define that yourself using options. Therefore, a solution is to replace:
lazy val list = initialize
by
private var _list: Option[List[Int]] = None
def list(implicit f: Bar) =
_list.getOrElse{
_list = Some(initialize)
_list.get
}
Then running Test.test
displays the expected result:
Case 1: with implicitp parameter from companion object
initialize called with Bar: 'some default bar' ...
initialize called with Bar: 'some default bar' ...
Case 2: with mixedin implicit parameter overriding the default one...
initialize called with Bar: 'mixed in implicit bar' ...
initialize called with Bar: 'mixed in implicit bar' ...
Case 3: with local implicit parameter overriding the default one...
initialize called with Bar: 'locally scoped implicit bar' ...
initialize called with Bar: 'locally scoped implicit bar' ...
Note that if you had mutable options, you could replace your lazy val with only two lines to get the same result.
private val _list: MutableOpt[List[Int]] = MutableOpt.from(None)
def list(implicit f: Bar) = _list.getOrSet(initialize)
Personally, I hope one day Scala will let us write this using one line:
lazy val list(implicit f: Bar) = initialize
which would be perfectly meaningful: At any time you want to access the value of the variable list, you need a Bar in scope, although only the first computation will matter.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With