As you may have guessed from the title, I've been hacking away at problems on Project Euler, and in fact have now managed to complete the first 25.
Much of my recent "acceleration" seems to have come from using Scala, as with these "one-off" coding exercises it's very helpful to have powerful functional constructs available when it makes sense to use them, but also to be able to fall back on a "normal" imperative style when it's more convenient.
Which will be first, though... reaching Level 2 or coming up with some "proper" code in Scala to really get a feel for how good it is?
Here are a few thoughts and code snippets from my admittedly brief experiments with dependency injection in Scala. Comments most welcome, as always!
Option 0: Use your favourite Java framework
I only know Guice, but I imagine the pros and cons are pretty much the same for any other framework. Porting Java annotations to Scala takes some getting used to, and occasionally it's a bit tricky to get right. And, of course, and it might not quite feel like Scala, but at least you'll know the framework and any quirks it may have.
Plenty of tutorials exist already for this option, so I'm sure your favourite search engine can help you find some. Any links I post here are sure to become stale pretty quickly given the rate at which Scala is developing.
Option 1: Just use implicits
Scala implicit parameters can easily cope with simple cases of DI, and have the added advantage that the code is somewhat more idiomatic Scala than would generally result from Option 0. For example, try pasting the following into an interactive Scala session:
trait Logger {
def log(msg: String)
}
object StdOutLogger extends Logger {
override def log(msg: String) { println(msg) }
}
object Config {
implicit def provideLogger = StdOutLogger
}
import Config._
def logTest(msg: String)(implicit logger: Logger) {
logger.log(msg)
}
logTest("Hello world")
One thing to note is that implicits operate at the function level, whereas DI is normally at the object level (via either constructors or setters). The former can easily be achieved via implicit parameters to an class's constructor, though. Following on from the code above:
class Test(implicit private val logger: Logger) {
def doSomething {
logger.log("Doing something...")
}
}
(new Test).doSomething
Option 2: Adding annotations to implicits
The approach above works fine when you're injecting fairly specific, single-purpose objects. But what if you wanted to inject a string or an integer. Typically DI frameworks use some form of annotation in these circumstances, so let's see if we can come up with a version for Scala implicits (again this should work if pasted into a Scala REPL):
class Annotated[A, T](private val t: T) {
def value = t
}
object DeepBlue {
def answer(implicit annotated: Annotated[DeepBlue.type, Int]) {
println(annotated.value)
}
}
object Config {
implicit def provideAnswer = new Annotated[DeepBlue.type, Int](42)
}
import Config._
DeepBlue.answer
Note that the example above, and the Annotated class in particular, is the simplest possible thing I could come up with that would work, and could likely be improved upon in several ways:
1. I used the (generated) class of the DeepBlue singleton object just because it was handy. Often you'd want to use a class or singleton object created specifically for the purpose. It might even be possible to use case classes or even enumerations to good effect here.
2. It doesn't do anything clever with the annotating type (A). One or more factory methods in a companion object which restrict their arguments a bit more (and maybe the addition of an Annotation trait to help with this) might lead to some nice type inferencing possibilities, especially with singleton objects as in the example. For instance, it would be nice to be able to write the RHS of the provider method as simply Annotated(DeepBlue, 42).
3. I might also be possible to mark the value method as implicit, and have the injection site implicitly convert from an Annotated[A, T] to a T when required. This might be one step too far, though, and just plain confusing rather than helpful (quite a common theme with implicits, unfortunately).
Option 3: For more functionality, implicitly pass an injector
If you need more advanced DI functionality then you may well hit the (somewhat ironic) restriction that all implicit functions (i.e. those that provide the values for implicit parameters) must be explicitly coded, i.e. there's no way (that I know of at least) to programmatically influence the resolution of implicit parameters. I've not spent too much time on this, but the obvious (to me, with my own unique set of influences/biases) way around this would be to build a Guice-like Binding/Module/Injector framework, and then implicitly pass the injector to functions which need injected instances of objects. It may even be possible to use Scala's flexible syntax to create a nice DSL for specifying the bindings. As a warning, though, I have not tried this (yet!) and I suspect it may involve quite a bit of reinventing the wheel, so at this point it may well be worth reverting to Option 0, and using an existing framework.
I hope this was useful, and happy coding!
Kids love computers and many would love to learn how to program them too. Lalit Pant, volunteer Math teacher at Himjyoti School for under-privileged girls in Dehradun, developed Kojo in his 'free' time. Kojo is a very polished, easy to install, cool IDE in which children, (or even grown ups) can learn to program using Scala. Lots of examples, a turtle to drive, good documentation and interactive geometry for those budding mathematicians. If you have kids then Kojo could be a fun experience to share with them. On the other hand if you have some 'free' time Lalit would welcome help to develop Kojo, an Open Source project, further.Just in time for the Easter holidays :)
trait Base {
type T
...
}
trait Super extends Base {
type T = String
...
}
trait Base[T] {
...
}
trait Super extends Base[String] {
...
}
trait Measure {
type K
type V
def aggData: Iterable[(K, V)]
}
trait Measure1[U, T1] extends Measure {
type V = U
type D1 = T1
type K = T1
}
trait Measure2[U, T1, T2] extends Measure {
type V = U
type D1 = T1
type D2 = T2
type K = (D1, D2)
}
trait PreAggregated extends Measure {
def data: Iterable[(K, V)]
def aggData = data
}
object ExampleMeasure1 extends Measure1[Int, String] with PreAggregated {
data = ...
}
object ExampleMeasure2 extends Measure2[Int, String, String] with PreAggregated {
data = ...
}
trait Measure[K, V] {
def aggData: Iterable[(K, V)]
}
trait Measure1[V, D1] extends Measure[D1, K]
trait Measure2[V, D1, D2] extends Measure[(D1, D2), K]
trait PreAggregated[K, V] extends Measure[K, V] {
def data: Iterable[(K, V)]
def aggData = data
}
object ExampleMeasure1 extends Measure1[Int, String] with PreAggregated[String, Int] {
data = ...
}
object ExampleMeasure2 extends Measure2[Int, String, String] with PreAggregated[(String, String), Int] {
data = ...
}
MeasureN ones, but this can get bloated very quickly, especially as it's likely that I'll need to support at least six dimensions. And repition also reappears when traits are stacked (e.g. to encapsulate storage and caching behaviours):trait Measure[K, V] {
def aggData:Iterable[(K, V)]
}
trait Measure1[V, D1] extends Measure[D1, K]
trait Measure2[V, D1, D2] extends Measure[(D1, D2), K]
trait PreAggregatedMeasure1[V, D1] extends Measure1[V, D1] {
def data: Iterable[(D1, V)]
def aggData = data
}
trait PreAggregatedMeasure2[V, D1, D2] extends Measure2[V, D1, D2] {
def data: Iterable[((D1, D2), V)]
def aggData = data
}
object ExampleMeasure1 extends PreAggregatedMeasure1[Int, String] {
data = ...
}
object ExampleMeasure2 extends PreAggregatedMeasure2[Int, String, String] {
data = ...
}
scala> def times(n: Int)(op: => Unit) = { (1 to n).foreach(_ => op) }
times: (Int)(=> Unit)Unit
scala> times(4) { println("Hello") }
Hello
Hello
Hello
Hello