Lazy vals and implicit parameters in Scala
Asked Answered
T

2

8

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:

  1. Explicitly passing an object to the method.
  2. implicit definitons defined in scope.
  3. Companion object of the class used as a implicit parameter

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?

Triangular answered 15/4, 2012 at 13:40 Comment(0)
A
4

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.

Acro answered 15/4, 2012 at 14:7 Comment(5)
Ok, but shouldn't it recognize the implicits? They are known at compiletime right? Perhaps it would work if I move the implicit parameter to the constructor?Triangular
It recognizes the only implicit Bar that is in scope at compile time, and that is the one in the Bar companion. Because list is only defined on Foo it will always use this one. You could define the implicit in your constructor, but the implicit in the trait would still not be in scope, as it only exists on the instance.Acro
So if I move the lazy val and initialize method to the NonDefaultBar trait and let that trait extend Foo and also move the implicit def to Foo, then I the compiler would know to grab the implicit def in Foo when evaluating the lazy val list?Triangular
It would be enough to just add override lazy val list = initialize in the trait NonDefaultBar.Acro
That is much nicer! As a note it also works if NonDefaultBar has Foo as it's self type, then it does not need to extend Foo... but I'm not sure what that actually does. self types are a mystery I need to explore ;) Thanks for the help, much appreciated!Triangular
T
2

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.

Typhogenic answered 22/3, 2017 at 15:12 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.