Another Tour of Scala

ImplicitParameters

The Gist

In Implicit Parameters, we learn how Scala’s concept of implicits goes beyond converting values from one type to another.

My Interpretation

Suppose you have a logging class and wish to provide a way to flexibly log lists of objects. You could create an interface for turning lists into strings, giving it a type parameter. Implementers would implement a simple method to make the transformation. You would then need to provide objects of these classes to your log statements, making sure to use the correct instance, depending on the type of objects in the list.

In Scala, you can declare the “map a list to a string” parameter as implicit, which allows you to omit this object when making the call. Scala will search for an object in scope that can be used automatically.

Here, the log messages are unencumbered by the mapper objects. Note that if we had a call like

logger.logList(List(true,false,false,true))

we would get a compile error, since there is no implicit object of type ListLogger[Boolean] in scope.

Also note how we have packaged the implicit objects inside the logger package; by importing them via import logger.Implicits._, Scala can find them wherever we are using the Logger class.

My Thoughts on this Feature

Like ImplicitConversions , this is a pretty cool feature, although it requires a lot of droppings to work correctly; I can see this being useful for creating DSLs. I’m not a fan of the alternate method call syntax; I don’t see why the compiler can’t just figure it out.