Scala dependency injection: alternatives to implicit parameters

A little late to the party, but have you considered using implicit parameters to your classes constructors?

class Foo(implicit biz:Biz) {
   def f() = biz.doStuff
}
class Biz {
   def doStuff = println("do stuff called")
}

If you wanted to have a new biz for each call to f() you could let the implicit parameter be a function returning a new biz:

class Foo(implicit biz:() => Biz) {
   def f() = biz().doStuff
}

Now you simply need to provide the context when constructing Foo. Which you can do like this:

trait Context {
    private implicit def biz = () => new Biz
    implicit def foo = new Foo // The implicit parameter biz will be resolved to the biz method above
}

class UI extends Context {
    def render = foo.f()
}

Note that the implicit biz method will not be visible in UI. So we basically hide away those details :)

I wrote a blog post about using implicit parameters for dependency injection which can be found here (shameless self promotion ;) )

The Scala standard library includes something like your hypothetical "usingContext" called DynamicVariable. This question has some information about it When we should use scala.util.DynamicVariable? . DynamicVariable does use a ThreadLocal under the hood so many of your issues with ThreadLocal will remain.

The reader monad is a functional alternative to explicitly passing an environment http://debasishg.blogspot.com/2010/12/case-study-of-cleaner-composition-of.html. The Reader monad can be found in Scalaz http://code.google.com/p/scalaz/. However, the ReaderMonad does "pollute" your signatures in that their types must change and in general monadic programming can cause a lot of restructuring to your code plus extra object allocations for all the closures may not sit well if performance or memory is a concern.

Neither of these techniques will automatically share a context over an actor message send.