#implicits

Back2Basics: The Magic of Implicit – #2

In our previous blog, The Magic of Implicit, we have talked about how implicit values are being used. In this blog, we will explore Type Conversion with implicit and implicit classes.

Let’s start with a simple example,

scala> val i: Int = 2.3 <console>:11: error: type mismatch; found : Double(2.3) required: Int val i: Int = 2.3

Here we were trying to assign a double type value to an

Back2Basics: The Magic of Implicits

Implicit System is one of Scala’s language greatest feature with the help of which we can write concise code. The implicit system in Scala allows the compiler to adjust code using a well-defined lookup mechanism.

In this post, we will try to understand how Scala’s implicit work magically.

Scala provides an implicit keyword that can be used in two ways: method or variable definitions, and method…

Solution: Where does Scala look for implicits? #fix #it #solution

Where does Scala look for implicits?

An implicit question to newcomers to Scala seems to be: where does the compiler look for implicits? I mean implicit because the question never seems to get fully formed, as if there weren’t words for it. :-) For example, where do the values for integral below come from?

scala> import scala.math._ import scala.math._ scala> def foo[T](t: T)(implicit integral:…

How to: What are Scala context and view bounds?

What are Scala context and view bounds?

In a simple way, what are context and view bounds and what is the difference between them?

Some easy-to-follow examples would be great too!

Answer: What are Scala context and view bounds?

I thought this was asked already, but, if so, the question isn’t apparent in the “related” bar. So, here it is:

What is a View Bound?

A view boundwas a mechanism…

How to: Where does Scala look for implicits?

Where does Scala look for implicits?

An implicit question to newcomers to Scala seems to be: where does the compiler look for implicits? I mean implicit because the question never seems to get fully formed, as if there weren’t words for it. :-) For example, where do the values for integral below come from?

scala> import scala.math._ import scala.math._ scala> def foo[T](t: T)(implicit integral:…

In previous post I described, how you can make side-effects in very concise way. There is one complementary operation that I also use a lot. This time it helps you to visualize the flow of the code. Let me demonstrate you this code:

case class Item(id: Int, name: String) def getItem(id: Int): Item = // ... def prepareForView(item: Item): Map[String, String] = // ... def renderPage(model: Map[String, String]): String = // ... def getItemPage(itemId: Int) = renderPage(prepareForView(getItem(itemId)))

You have probably already saw this kind of code a lot. Such method chaining, that I showed in body of the getItemPage method, is pretty common. I personally find it awkward - the code flow is turned inside out. I call the method renderPage at first, even if this is something that would be used only at the end and produces the result value of the whole function. My brain just work in other direction: When I'm writing this code, at first I think, how I can get Item from id and then, how can I get the model for the view ... and finally how to produce page. We can do better!

What we can do is to define another small implicit conversion:

object WorkflowHelper { implicit def anyWithWorkflowHelpers[T](target: T) = new { def |>[R](fn: T => R) = fn(target) } }

It adds |> method to any object and allows us to provide some function that transforms it's argument to something else (definition is even easier than ~ method defined in previous post).

Now let's try to use it:

import WorkflowHelper._ def getItemPage(itemId: Int) = getItem(itemId) |> prepareForView |> renderPage

Now it feels much more natural, isn't it?

Ok, in this example for every bit of it's logic I had some other function. It's also common, because we often split our logic in several smaller pieces and than have some main method that calls them all. But sometimes methods do not have suitable signature. For example prepareForView most probably will also require locale:

def prepareForView(item: Item, locale: Locale): Map[String, String] = null

But in order to handle this we can use vary nice Scala feature called currying. It allows use to adapt prepareForView method to our needs:

def getItemPage(itemId: Int) = getItem(itemId) |> (prepareForView(_, Locale.ENGLISH)) |> renderPage

In this case underscore plays the role of placeholder. You generally saying, that provided Item instance should be inserted here.

But wait... often we have more than one object to deal with! How can we handle this? Let's say, we have also User in play which also should be prepared for view. This time tuple comes to rescue. Here is how we can implement this:

def prepareForView(item: Item): Map[String, String] = // ... def prepareForView(item: User): Map[String, String] = // ... def renderPage(model: Map[String, AnyRef]): String = // ... def getCurrentUser: User = // ... def getItemPage(itemId: Int) = (getItem(itemId) |> prepareForView, getCurrentUser |> prepareForView) |> {case (item, user) => renderPage(Map("item" -> item, "user" -> user))}

In this case I prepare tuple and give it to the another function. Actually it's partial function, that's because I'm also able to make pattern matching directly there! Of course, you can make it a little bit differently and prepare complete model for the page first and then just render the page:

def getItemPage(itemId: Int) = Map( "item" -> (getItem(itemId) |> prepareForView), "user" -> (getCurrentUser |> prepareForView) ) |> renderPage

I'm not claiming, that |> method is useful in any situations, but I definitely believe, that there are a lot of situations where it can make code more readable and easier to write.

Sometimes I find myself in following situation: I have nice one-expression method like this:

def formatUsers(users: List[User]): String = users.map(_.userName).mkString(", ")

Now I want to print the results to the System.out in order to quickly check the result that this function produces.

Common way of solving this problem is to write something like this:

def formatUsers(users: List[User]): String = { val result = users map (_.userName) mkString ", " println(result) result }

Too much code for such trivial task. In Scala we can do better than this!

Here is the way you can improve it. At first we need to define small implicit conversion:

object SideEffects { implicit def anyWithSideEffects[T](any: T) = new { def ~(fn: T => Unit) = { fn(any) any } } }

With this code I can make ~ method available on any object. The only thing it does - is executes function you provided and returns original object. So the result of this function is completely ignored (that's because it's return type is Unit), but it's Ok for our purpose - it's exactly what we want to archive here.

Ok, now we can use it. Here is my first attempt:

import SideEffects._ def formatUsers(users: List[User]): String = users.map(_.userName).mkString(", ") ~ (s => println(s))

And, as you can guess - it works. But we can do even better! println is also functions that accepts one argument, so we don't need to wrap it in another function:

def formatUsers(users: List[User]): String = users.map(_.userName).mkString(", ") ~ println

Now it looks much better with much less code, isn't it?

You also can use it everywhere in expressions. Here is another example:

def formatUsers(users: List[User]): String = users.map(_.userName ~ println).mkString(", ")

It just prints all processed user names for me.

Generally side-effects is not very good thing, but sometimes than can be helpful. Debug output, that I demonstrated, is one example. Another good example is integration with Java, which consists mostly of side-effects. Let's look in this code:

val frame = new JFrame frame.setVisible(true) useFrame(frame)

You probably already guess how we can improve this situation. Of course with our brand new, shiny ~!

useFrame(new JFrame ~ (_ setVisible true))

Hope you will find it helpful and enjoyed this post.

Small update about theoretical grounds

Seems that this approach even has some theoretical grounds. So if you are interested, it's called K combinator and you can find some information about it (with code examples in Ruby) in this post.

Actually that post reminds me on another use case for the ~ method, that I'm using sometimes. It looks like this:

def createFrame = new JFrame ~ { frame => import frame._ setVisible(true) setTitle("Test Frame") setSize(200, 100) // ... }