Someone asked me today how to write a service so its API can be used from Java. His problem is that he is using Scala's collection classes but it is not possible to use their methods from Java. This is because when using some features of Scala, the encoded method has a name that is not legal in Java (using '$' in particular).

For example:

trait API {
  def service: Map[String, String]
}

If we call the method 'service' from Java, there's very little we can do with the result.

The common wisdom is to create an adapter class that exposes Java consumable classes. Say, create a JavaAPI interface and JavaAPIImpl. This is very tedious and also tends to become very verbose since if another API interface returns our API interface it also requires wrapping so it will return a JavaAPI interface.

This post is not yet another introduction to Monads. In fact, I hesitated whether to use the term in the title. Eventually I did, so I wouldn’t get comments that the article is in fact about Monads. It is, but not for the reasons most articles are about.

I want to discuss the design pattern that they offer. That is inversion of control between values and functions. Usually we think as values being the arguments to functions. But if we switch things around, making functions the argument of values, it can help make some code more concise and clear. It helps to model different code flows than foo(bar(car()))

Since I mentioned the word Monad, I need to give some kind of introduction. It is very superficial. I will then follow with some examples.

Sometimes Scala's compiler will infer the type Nothing for a generic type parameter which may cause an error during runtime. I show here a simple way to avoid that.

The method follows the strategy in http://github.com/harrah/up/blob/master/Contains.scala (which presents a more generalized way of declaring type parameters which are required or excluded). The strategy is to cause an ambiguity for the compiler when Nothing is used which will cause it to error.

First, a use case: Say I want to make working with Maps that contain multiple types a little easier, for example, working with a Map[String, Any]. Insted of a user needing to call map.get(key).asInstanceOf[Option[MyType]] , I want a method like map.getAs[MyType](key). The code:

It looks like the recent trend is blogging about scala-complexity. I thought of writing my own view of things.

Mixing up complexity and limits

Scala has its limits. Some things cannot be done easily. The thing about Scala is that it makes people believe they can do anything with it, they are then frustrated when they can't. The scala-complexity blog post for example, tries to create a method that will work on collections, Java's strings and Java's arrays. Seamlessly. This is something you wouldn't even dream of doing in Java (Note: it is in fact possible to do it.)