Fork me on GitHub
Posterous theme by Cory Watilo

Introduction to Type Dynamic

In Scala 2.10 class Dynamic would be enabled by default, so I think that it’s the right time to look at it in more detail. This class can be used for many different purposes. I think, that an integration with dynamic languages is the most obvious one, but I would like to show you something different. I will demonstrate you how to create parameterizable extractors, that can be parametrized directly within case expressions.

Class Dynamic works very similar to Ruby’s method_missing or Groovy’s methodMissing/propertyMissing. So you can call non-existing methods on classes that extend Dynamic. Such calls would be rewritten by compiler to following method invocations: applyDynamic, applyDynamicNamed, selectDynamic, updateDynamic. I will describe each of these methods in the next sections.

applyDynamic

It’s, probably, the most popular method. You can define it like this:

class DynamicTest extends Dynamic {
    def applyDynamic(methodName: String)(args: Any*) {
      println(s"You called '$methodName' method with " +
          s"following arguments: ${args mkString ", "}")
    }
}

And as you can see, I can call non-exiting methods on instances of the DynamicTest class:

scala>  val test = new DynamicTest
test: DynamicTest = DynamicTest@fb7ac7

scala>  test.method1("a", "b", 123)
You called 'method1' method with following arguments: a, b, 123

scala>  test method2 "testing"
You called 'method2' method with following arguments: testing

applyDynamicNamed

I find it very nice, that named arguments are also supported. Each argument that you pass to the function is converted to the Tuple where the first element of the tuple is argument name and the second is value. Here is its signature:

class DynamicTest extends Dynamic {
    def applyDynamicNamed(name: String)(args: (String, Any)*) {
        println(s"You called '$name' method with " +
            s"following argiuments: ${args map (a => a._1 + "=" + a._2) mkString ", "}")
    }
}

And it’s usage (as you can see, argument name would be empty string if you don’t use named argument):

scala>  test.createUser("abc", name = "John", age = 20)
You called 'createUser' method with following argiuments: =abc, name=John, age=20

By the way, in all examples above I have used Unit as return type, but you actually not limited to it. You can return anything you want from these methods, you can even have as many type parameters as you want.

selectDynamic

Now comes setter/getter method (properties) support. If you want to handle method invocation, that does not involve any arguments or parenthesis, than you need selectDynamic – it’s probably the simplest of them (still it can be very useful as you will see later in my bigger example). You can define it like this:

class DynamicTest extends Dynamic {
    def selectDynamic(name: String) = s"value of $name"
}

And it’s usage:

scala>  test.firstName
res0: String = value of firstName

scala>  test.`some other property ?`
res1: String = value of some other property ?

updateDynamic

This is setter part. You can use it to handle assignments. It’s signature:

class DynamicTest extends Dynamic {
  def updateDynamic(name: String)(value: Any) {
    println(s"You have just updated property '$name' with value: $value")
  }
}

I actually had issues with this one. If you will try to use it in REPL (and some other contexts), you will get something like this:

scala>  test.firstName = "John"
:12: error: value selectDynamic is not a member of DynamicTest
val $ires0 = test.firstName
             ^

Seems that compiler treats it as getter, and tries to find selectDynamic. I think, that the reason for this is a snapshot version of Scala 2.10 compiler that I currently using. So let’s hope that it would be fixed soon. Meanwhile, you can test updateDynamic like this:

object MyApp extends App {
  val test = new DynamicTest

  test.firstName = "John"
}

This works as expected and prints:

You have just updated property 'firstName' with value: John

Parameterizable Extractors

This was my dream for a long time! Wouldn’t it be nice, if you can specify regexp directly in pattern matching expression instead of defining it elsewhere and then use your variable in pattern match or to extract specific elements of the Map? With type Dynamic you can actually archive this, and here is example it’s usage:

Map("firstName" -> "John", "lastName" -> "Doe") match {
    case p.firstName.lastName.Map(
          Some(p.Jo.StartsWith(fn)),
          Some(p.`.*(\\w)$`.Regexp(lastChar))) =>
      println(s"Match! $fn ...$lastChar")
    case _ => println("nope")
}

As you see, I have provided parameters to the extractor and performed pattern match in the same case expression. One selectDynamic is enough to implement it:

class ExtractorParams(params: List[String]) extends Dynamic {
  val Map = new MapExtractor(params)
  val StartsWith = new StartsWithExtractor(params)
  val Regexp = new RegexpExtractor(params)

  def selectDynamic(name: String) =
    new ExtractorParams(params :+ name)
}

object p extends ExtractorParams(Nil)

As you can see, each call to the selectDynamic adds on parameter to the parameter List, and when I’m finished with parameters, I can call concrete extractor like StartsWith or Map. These extractor implementations are pretty straightforward:

class RegexpExtractor(params: List[String]) {
  def unapplySeq(str: String) =
    params.headOption flatMap (_.r unapplySeq str)
}

class StartsWithExtractor(params: List[String]) {
  def unapply(str: String) =
    params.headOption filter (str startsWith _) map (_ => str)
}

class MapExtractor(keys: List[String]) {
  def unapplySeq[T](map: Map[String, T]) =
    Some(keys.map(map get _))
}

Conclusion

I hope you enjoyed this small introduction to new type Dynamic. I also hope, that I was able to demonstrate you, that it can be used for pretty unexpected use-cases and not only for integration with dynamic languages. You can find more information about Dynamic type in the correcpondent SIP-17.

Progress Monitoring For Streams

In this blog post I would like to show, how you can implement simple monitoring capabilities for standard Java’s InutStream and OutputStream. By “monitoring capabilities” I mean ability to find out information like Speed, Estimated Time, Transfered Size, etc. Recently I implemented this for our internal deployment tool (simple Swing-based application written in Scala). After about 30 minutes of googling without much success, I actually tried to think about this and found out how simple it actually is. So I decided to share this with you. Additionally I also want to give you small demonstration of scala-swing which I’m enjoying a lot.

After reading this article you will find out how you can write application like this one:

Creating Stream Filter

In order to get all metrics shown above, we need to know the full size of the file/stream and currently transfered amount of bytes. The full size is easy to find out from outside of the Stream, especially if you are working with files, but we need to monitor Stream in order to find out how much bytes are transfered already. Here is an example of such InputStream, that reports this with specified threshold:

You have probably noticed ProgressListener. It’s function Long => Unit which we will discuss next.

ProgressListener class

In order to show transferred number of bytes, we need to remember it somehow. ProgressListener function makes just this + calculates another metrics:

What’s interesting about this, is that I do cont define function with function literal like: (bytes: Long) => Unit. Instead I’m creating a new class that extends Function1[Long, Unit] – it’s allowed in Scala and sometimes can be very useful. Actually many Scala’s collection classes also making this, so you can get i-th element of the list like this: myList(i). In my case, it allowed me to have some internal state (transfered and startTime fields) and to parametrize function with some arguments (availableBytes and tracker) during it’s creation. It’s also possible to use function literal for this and still archive the same results – you just need to use currying and closures in this case. But I find, that it’s more clear and readable to define ProgressListener as class in this particular case.

You can tweak this algorithm and make it more accurate. For example you can calculate bps depending on the bytes, that were transferred during last several seconds. Still I think, that this algorithm does it’s job for many use cases.

Progress class

Now let’s take a look at Progress case class. It’s purpose is to hold different metrics and format it when needed (formatting can be probably done somewhere else, but I decided to put it here just to keep it simple).

Here you can also find nice utility functions to format size and time.

User Interface With Scala-Swing

Now let’s create simple application that downloads files and shows the progress:

This application throws all downloaded bytes away, so it’s pretty useless, but I hope that it will demonstrate you scala-swing basics.

Conclusion

Hopefully this will also give you some impressions on how easy it is to integrate with Java standard library from Scala. For your convenience I also created gist with all these classes in it, so you can just copy/paste it in your own projects and start playing with it.

Scalaz - Resources For Beginners

Scalaz is very interesting Scala library. It can be pretty scary when you first look at it and at examples of it’s usage. I also find, that at the beginning, advantages of this library are not very obvious. So at some point I asked myself: why are people so enthusiastic about it? So I started to learn it, but found that it’s hard to find any resources that are targeting beginners – people who are new to Haskell, Category Theory, or advanced Scala features like Type Classes or Higher Kinds.

In this post I want to summarize all resources I found about scalaz or related to scalaz that are actually approachable by beginners. I started with question at StackOverflow where I received many good answers. I also noticed, that this question was pretty popular, so I decided to write this post where I can summarize the answers and maybe add something more.

I personally believe that even if you don’t completely understand every aspect of scalaz yet (I’m definitely not), it still can help you to write a better code. As far as I can can see, it helps to write more composable, reusable and side-effect free code. But in order to use it, you need to understand some key concepts that it heavily relies on. So let’s start with …

Type Classes

Type Classes playing important role in Scala and they are really useful concept. They generally allow you to define some additional behavior (methods) to the class independently from this class itself. I believe, that this concept was taken from Haskell and implemented in Scala with the help of implicit parameters. Type classes can also help (at least partly) to solve Expression problem. You can find these presentations helpful on this topic:

I can highly recommend Nick’s presentation – it’s mostly not about Scalaz, but about the concepts it uses. Step by step, he implements these concepts in a simple example. For me personally it was eye opening. Heiko shows some of the features of Scalaz, including interesting of type-safe equals implemented with type class.

I can also recommend you to watch Daniel’s presentation, described in the next section, which touches this topic.

Higher Kinds

Values are to types as types are to kindsDaniel Spiewak

It’s very nice feature of Scala language, which allows you to work with containers like List or Option in very generic manner. I highly recommend you this watch this presentation on this topic:

Daniel describes 3 concepts: Higher Kinds, Type Classes and Continuations. He also shows, how you can implement heterogeneous list with this knowledge, as an example.

Scalaz Itself

Here are some inspiring presentation about scalaz, which I would highly recommend:

in these videos Chris gives introduction to some useful features of Scalaz, describing them from the more practical perspective.

Here are some other resources for beginners:

Lenses

Lenses are generally something similar to getters and setters in function world. Here are some useful resources about them:

Category Theory

In the hart of Scalaz (as well as Haskell) lies category theory. It’s interesting topic, but can be somehow involving. Heiko Seeberger wrote a great articles on this topic, which I find very beginner-friendly:

If you still wonder what monad is, then following video will definitively give you some hints. I also find it very friendly to Java developers, that want to find out what actually monads are and their advantages. Video includes explanation of Option, Validation and List monads:

A lot of ideas, implemented in Scalaz, are borrowed from Haskell, so it can be helpful to learn some Haskell too. You can find a lot of information on this topic in this chapter of Learn You a Haskell for Great Good! book:

Conclusion

I found, that absorption of completely new concepts, is pretty hard and slow process where getting motivated is very important. I hope, that this material will motivate you and would be helpful in you thirst for knowledge.

If you know some other resources about Scalaz, then please share them with me – I would be very grateful and they will help me to enhance this post with even more material.

Every Project Needs a Home

Scaldi-pamflet-b

Recently I created home page for my project Scaldi. I wanted to make it for a long time, but from the other hand I don't want to spend much time finding some hosting and maintaining its infrastructure, making page design, etc. Github page is nice, but still I would like to have somethng more simple and unique as a project's front page. So my main goals were:

  • Use very nice feature of Github - gh-pages to host my pages
  • Use markdown to create my pages without spending much time making page design
  • Design that comes out-of-box should be clean and pretty
  • Integrate pages generation and publishing in SBT build process

Pamflet

And I finally found solution that addresses all these requirements. Pamflet is very nice Scala library that allows you to define your site using markdown. It's very easy to use: you just create your pages that are named according to their position in the resulting table of contents with .md or .markdown extension. You can also define some properties in the template.properties which you can use in your pages (they would be processed using StringTemplate). If you want, you can add some custom CSS in order to make it even more prettier. So resulting file structure should look like this:

  • 00.md
  • 01.md
  • 02.md
  • custom.css
  • template.properties

Pamflet has even more features, but it was enough for me to start creating Scaldi's home page. So I ended up with following files in my project's docs folder. It was pretty straightforward to create, but now I need to generate actual HTML from my markdown markup.

SBT Integration

In order to generate my pages and publish them to the gh-pages I need following SBT plugins:

At first you need to create  gh-pages branch in your git repository. You can make it like this:

After executing this, you need to add SBT plugins in your project/project/Build.scala:

After adding these plugins, you should be able to generate HTML pages. All you need to do is to execute write-pamflet task and your pages would be generated in target/docs folder.

Now comes your main build.sbt file:

I hope comments will help you in understanding what each of these settings does. So now in order to publish my pages I need to execute ghpages-push-site task. I can also run ghpages-synch-local in order to add pages to the gh-pages branch locally.

As bonus, Scalasodocs would be also published by xsbt-ghpages-plugin.

Conclusion

It was pretty easy to integrate Pamflet with SBT and gh-pages. I ended up with nice looking site and published Scaladoc. And it's really easy to manage and publish them.

I hope this post will also help you to setup your project's home page in a matter of minutes, because, you know, every project needs a home :)

Conceptual Surface Area of the Project

In this post I want to address (and express my opinion) some of the concerns described in fhil’s comment to my previous post about Scala Complexity vs Book of Magic Spells.

Conceptual Surface Area

First, I want to agree on concerns about language complexity, but I want to look at bigger picture. Scala the language has more concepts in it and from the language perspective it’s more complicated than Java. From my experience, every project bigger than HelloWorld involves heavy usage of libraries (including standard library). In my previous post I tried to take more higher-level view of the language, so I would like to keep this aspect in scope of our discussion. The problem with Java is that many libraries like Spring, Hibernate, EJB, AspectJ, etc. add completely new concepts which are pretty unique to each of them. And believe me, If you are creating real-world Java project (even small) you are expected to learn and understand a lot of new concepts introduced by these libraries (just try to search job sites for Java position and I assure you, most of them, of not all, require you to know a lot of libraries like Spring or Hibernate). I see Scala as product of evolution of other languages that absorbs new concepts in a language level that has proven to be useful or even essential. So Scala libraries can actually express themselves in terms of these concepts. Your real-world project becomes more simple, regular and consequent in terms of conceptual surface area. Just take a look at Unfiltered web framework, and how elegantly it leverages pattern matching, if you want to see an example. As application developer I care much more about project’s conceptual surface area rather than language’s conceptual surface area because language is common knowledge and if you invested some time and learned the Scala language you can jump in any Scala project and be very well prepared for the concepts you will face. It’s often not the case with Java because knowledge of reflection API and Annotations or even Java the language itself would be of little help in understanding new concepts that project or libraries introduce.

This reminds me of difference between Ant and Maven/Gradle/SBT/Leiningen. In Ant you have very small conceptual surface area. The result of this is that in order to understand what ant script actually does you need to look in it and understand all new concepts that it introduces (on top of ant). Maven, from the other hand, introduces much wider conceptual surface area, and yes, you need to learn it if you want to work with Maven. But as advantage, I can take namely any Maven project and run mvn install or mvn package on it without even looking in pom.xml. I even can run mvn jetty:run because most of the plugins reuse concepts introduced by Maven and stick to them. Concepts like project, dependency, project’s version, project’s name, etc. are proven to be very useful and even essential to most (if not all) Java projects. So I also see Maven and similar build systems as product of evolution where common and useful practices, patterns and concepts are introduced directly into the core system itself.

Maintenance Concerns

Now I would like to address concerns about maintenance – I actually disagree with points in the comment. I believe that in long run, Scala project can remain very maintainable. The reason for this is static typing and the fact that it’s very well accepted and practiced in Scala community. It’s much easier to maintain an application if you don’t even need to run and debug it in order to understand it’s behaviour and interaction/connection between it’s components. I don’t want to say that Scala completely eliminates necessity in debugging or running you application in order to understand it’s behaviour, but it can make it unnecessary in many cases. Let’s take perspective of new developer that jumps into the existing Scala project trying to understand it. What tools does he have in his toolbox? First and most important, from my point of view, is IDE – I can navigate code easily with the help of it. I use Intellij IDEA and I can use CTRL + Click almost everywhere. I can run search for usages and make complex refactorings without relaying on the wild guesses from the IDE based on the full text search and very very smart results analysis (which is the case with many dynamic languages and even with Java when you externalize part of your application’s logic in XML, text or any other non-java files). Scala aids your development with things like implicits but sill keeps this static link between application components that makes it possible to analyze code without resorting to full text search or debugging. I believe that static typing and generally static nature of the language plays very important role in ability to maintain and grow the project. I already faced problem several times when developers just fail or refuse to maintain (even good structured) JavaScript project because of dynamic nature of language and very poor tools support (and I doubt that these tools can improve any further). Nowadays Java project contain so many dynamic elements, that I’m really concerned about their maintainability.

Also I don’t expect non-scala developer to maintain Scala project in the same sense, that I’m not expect Java developer, who knows nothing bout Spring or Hibernate, to main Java project that uses these libraries. Still in case of Scala I at least can be sure that IDE and compiler can really aid him and guard him to some extent from failure (to much greater extent than Java compiler does).

Subjective Stuff

And lastly, I would like to avoid discussion of highly subjective topics like language syntax. I believe that it’s comparable to personal taste and is the matter of habituation. And we just can’t expect all general purpose languages in this world to have the same syntax, especially the one you personally prefer.

New features in Scala 2.10

Today was most awaited (by me) talk of Devoxx. Martin Odersky gave presentation and announced a new features in the Scala 2.10. I just want to quickly go through all of them:

  1. New reflection framework - it looks very nice (see photo) and 100% Scala. No need for Java for reflection API in order to work with Scala classes anymore!
  2. Reification - it would be limited
  3. type Dynamic - something similar to .NET 3
  4. IDE improvements
  5. Faster builds
  6. SIPs: string interpolation and simpler implicits

At the moment it's not clear whether mentioned SIPs would be really included in the release, but the chances are pretty high! So yes, we will finally get string interpolation!  

Reflection is very cool and it's also very interesting how it's implemented (I saw a lot of cakes :). Most (if not all) code is shared between compiler and library (Scala Reflection API).

And it would be shipped during next 6 month! 

View more presentations from Odersky
Update
You already can watch Martin's Devoxx talk at Parleys, but you need subscription in order to do this. I hope it would be available freely soon. Meanwhile, you can find more recent video, where Martin Odersky gives overview about new features in Scala 2.10 at SF Scala user group here:

(download)

 

Scala Complexity vs Book of Magic Spells

Today was the first day of the wonderful Devoxx conference. I got a lot of positive impressions, but what I want to share with you today is something different. Today I was reminded about recent buzz about Scala complexity. I hear a lot about this recently, but I still fail to understand some aspects of it.

In order to describe my point of view I would like to talk about Java complexity. Let me ask you a question: How complex Spring or Hibernate frameworks are? Some of you may say, that they are pretty simple (especially in comparison to EJB 2). But why is it so? Do you really believe that they are that simple… or may be they are just familiar? I think we can view these frameworks from 2 perspectives: from user perspective and from library developer perspective. I don’t think that you expect all developers in your team to actually be able understand, how Spring/Hibernate is internally implemented. You want them to be able to use these frameworks and understand their purpose, ideology. What does it actually take to understand their internals? Which knowledge about Java can help them to understand these frameworks? Actually users should edit XML files or add annotations in their code and with the help of the Spring/Hibernate magic interesting things will happen. Spring will magically instantiate object and wire them. Hibernate will be able to load/save objects from/to the database. Do you really expect new Java developer, which you want to hire, to understand how exactly this magic works?

I want to talk more about this “magic”. Java reflection lies behind most of the modern popular Java frameworks. What does it actually means? We are just compromising the safety, performance, common java semantics of our code for convenience. Today I watched interesting talk from Spring guys called “Spring Data JPA – Repositories done right”. To make long story short, one part of these new API will allow you to write interface like this:

interface UserRepositry {
    User findByFirstNameAndLastName(Sting firstName, String lastName)
}

Library will “parse” method signature and generate JQL query and all plumbing code for you… When I see code like this, Spring or other similar library looks more like book of magic spells to me rather than library or API. And I already can predict the first question of junior Java developer (after hours of code search): Where can I find UserRepositryImpl? (I still have a hard time explaining young java developers that these XML tags out there are actually creating new instances of Java classes and injecting them into other objects)

And what can i answer? No, really, is there any standard way to find answer for this puzzle, except looking into the “Spring Data Reference Manual”? I’m pretty sure that this library will have good documentation. Spring always has excellent reference manuals. But what about Javadoc? As was noted today, the first place new user will search for the help is in the examples and Javadoc. But we can’t have it anymore. Actually we don’t have any semantics of the library in the code, we just replaced public API with reflection and externalized semantics in the reference manual. Sometimes I have situation in which I can’t find solution to my problem in the documentation. In such moments I just need to look in the source code of the library… but where should I start my journey? Definitely not from UserRepositry interface…

Seems that each library adds it’s own kind of magic in the project. Then problem Is that the only common concept they have is usage of reflection. For example, can I apply my knowledge about Spring in order to better understand how Hibernate works? Seems that Scala’s map method from the collections API is pretty popular example that frightening people. But the signature of the map method is simply uses concept called Type classes . This concept adds great flexibility of the code, but also requires you to understand it, if you want to understand why map method will return you new Set[String] when you are executing it on BitSet and converting each bit to String. Actually this concept of Type classes is very common and a lot of Scala libraries are using it. Even Scala itself is using it a lot. Naturally you can invest your time in order to understand how Scala collections work (if you want, but you don’t have to, you can just use map method according to the use case in the scaladoc for this method and treat it’s method signature as a magic). But when you actually invested this time and understood it, you have learned a bunch of concepts along the way that will make your understanding of other completely different library much much easier.

In Java world you can invest time in understanding Spring school of magic, but it won’t be of any help with Hibernate’s one. From the other hand in Scala you have set of concepts that are shared between all the libraries. I also believe that Scala brings us more safety and can free us from the reflection craziness that has got a lot of popularity in Java wold recently. Also notice, that magic has not proven itself to be very reliable. It can always fail you at Friday evening a the production environment. I don’t think that in most cases Scala actually adds more complexity, it just offers you to explore new world were magic is replaced with technology which solves the same problems but in more consistent and regular way.

So my point is: You don’t need to worry about Scala’s complexity. Actually I believe that this topic is relevant only to library developers who want to make it very robust and very general. With Scala they actually have much better opportunity to make your code more safe and faster. This philosophy goes even in language design: Have you ever tried to use Java generics with all these wildcards and definitions of co/in/contravariant types? Several weeks ago I tried to use it and ended up with something like:

Map<String, ? extends Type<Integer, ? extends Map<String, ? extends List<String>>>> result = // ...

Java forces you to actually know how exactly variance works. I believe that it’s too complicated to get it right. From the other hand in Scala, variance information is described in the type definition itself, so, as user of the library, you don’t have to understand it. According to Scaladoc type parameter of immutable list is covariant, for the mutable list it’s invariant and in function it’s arguments should be contravariant and result type covariant. Can you explain why? Last time I thought about it, it took me about 1 hour of mental work before I got more or less clear understanding. And after about 5 minutes I have lost the focus and landed at the same point where I started. The problem is that Java forces you to understand these concepts if you are going to use them. In Scala, library designer can save your time and do this for you.

Hope you enjoyed this post. As always, any feedback is highly appreciated!

PS: By the way, I have nothing against the magic. If it would really exist in our world I’d probably become Archimage rather than developer :)

Composing your types on fly

Let me show you class from one of my projects:

class FileTransferHandler extends TransferHandler with Publisher {
    // ...
}

TransferHandler is swing class that generally handles copy/paste and D&D stuff. Publisher is trait that comes from scala-swing. So I generally composing here 2 independent things and making then work together.

As next step I define method, that requires it’s argument to be both – TransferHandler and Publisher. In my codebase I have only one type that extends both of them, and it’s FileTransferHandler. So I can use it to define my method, right?

def register(handler: FileTransferHandler) {
    // ...
}

The problem here is that the body of the register method does not care whether handler is FileTransferHandler or ImageTransferHandler or even StringTransferHandler. It only requires it to be TransferHandler and Publisher. And it’s exactly what Scala allows you to express using with keyword! So now we can write improved version of register method:

def register(handler: TransferHandler with Publisher) {
    // ...
}

So you don’t actually need any concrete class or trait to express such constraint.

Combining with structural types

Scala has very nice feature called structural types. Let me describe it to you in example. Recently I was writing some Scala tests for Java classes. It appears, that a lot of classes had methods like init() and destroy(). Not all classes had both of them – some need only to be initialized, but don’t require explicit destruction and vice versa. Also there are no interfaces for this – they all were normally instantiated using spring with something like

<bean class="..." init-method="init" destroy-method="destroy" />

Structural typing helped me a lot to deal with such classes. I was able to define methods like this one:

def cleanup(list: List[{def destroy()}]) = 
    list foreach (_.destroy())

Next I would like to define method, that will initialize and destroy objects automatically for me, because I can just forget about one of these steps. So here my first attempt:

def safe[T <: {def init(); def destroy()}, R](t: T)(body: T => R) =     
    try {
        t.init()
        body(t)
    } finally {
        t.destroy()
    }

safe(new PaymentService) { service =>
    service.makePayment()
}

So it works! But can we implement it better? The problem here – is that we repeating ourselves. I already used signature of destroy method in the cleanup method, and I don’t want to repeat myself again. It would be nice to define some traits/interfaces like Init or Destroy, but I don’t want to change all existing classes in order to implement them. Actually I even don’t need any concrete trait for this – I just need to define some kind of alias for {def init()} and {def destroy()}.

Type aliases serve exactly this purpose. Let’s define them:

type Init = {def init()}
type Destroy = {def destroy()}

Nice, now I have pretty names for the structural types. safe method needs both of them and, as you probably already guessed, I can combine them using with:

def safe[T <: Init with Destroy, R](t: T)(body: T => R) = // ...

If you wish, you can also define type alias for the combination:

type InitDestroy = Init with Destroy

def safe[T <: InitDestroy, R](t: T)(body: T => R) = // ...

Hope you enjoyed.

Inverting the flow of your code

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.

By the way, I’m not the first one who came up with this idea. For example scalaz’s Identity trait also has |> method which has exactly the same signature and purpose.

Side-effecting without braces

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)
    // ...
}

I like this pattern because it makes intent of the code much cleaner and visually splits method in 2 parts: the first one defines object you want to return and the second configures it.