One limitation we still had was that we didn’t really know the complete set of required imports, but this is required to, for example, replace all wildcard imports with the actually used ones. Another request was that it should be possible to push import statements down to the scope where they are used. For this, we also need to know which parts of the code require which imports.

Yet another motivation to write some code to analyze dependencies was that I want to provide a move refactoring, and for this too we need to know some of the dependencies in the code. But that’s for a future post, back to what we have now:

As you can see, just like the JDT, we can now configure grouping for imports (groups are separated by a blank line), and it’s possible to expand or collapse imports from the same package. The Scalaz or Lift users will likely want to always use wildcard imports on some packages and types, so this is also possible. The JDT has some additional options, but I think I implemented the important ones.

And there’s more! No, not Reversi, but if there are missing imports in the file, Organize Imports will add them for you:

This all is part of the latest beta release of the Scala IDE, so please give it a try and open a ticket if you find a problem.

What I also liked very much was Scala’s consistent use of the Option type in its standard library. Now, instead of having to read the documentation to find out whether some call could return null, the type checker forced me to handle this where necessary. So a lot of my early Scala code looked as follows:

doSomething() match {
  case Some(value) => Some(doSomethingElse(value))
  case None => None
}

While it’s still possible to get a NPE in Scala, it just doesn’t happen with well-written libraries, simply because there’s no need to ever use null.

(By the way, isn’t it funny that Java forces you to check exceptions but doesn’t help you with the much more common and annoying null problem?)

So yes, in practice, Options do save you from NPEs. Does your code also get smaller (because usually, in Scala it will)? Not if you pattern match on Some/None, all the un-wrapping and lifting is quite verbose.

Nowadays, certainly influenced by all the discussions on monads, I realize that pattern-matching on Option is a very primitive form of abstraction, and instead of the code above I now write:

doSomething() map (value => doSomethingElse(value))

(For those unfamiliar with functional programming, map applies the function to the value inside a Some, and does nothing when called on a None.)

Even better, we can fully automate this refactoring! I’m currently working on a first version in the scala-refactoring library. So far, I’ve implemented the refactoring for map, but there are many more we can do, for example:

• If the Some case does not construct a Some but calls a function that returns an Option, we use flatMap instead of map.
• If the Some case evaluates to Boolean and the None case returns false, we can replace it with exists. If Some returns true and None returns false, we can just replace the whole pattern match with isDefined.
• When the None case is (), we can transform to foreach.

So far we have only looked at Option, but there is more: for example, we could also replace pattern-matching on lists and recursion with folds. I’m sure somebody has already written a paper about such refactorings, but I haven’t found anything yet.

What do you think about eliminating pattern matching? Do you also prefer mapping to explicit pattern-matching?

I’ve spent a large portion of last year on the Scala Refactoring project, and I’m quite happy with the results: four editors/IDEs are using the library to do refactoring, plus others use parts of it to manipulate or generate Scala source code.

It’s clear that I cannot continue investing as much time into it as during my master thesis (except of course, if someone would be willing to sponsor me ). My plan for this year is to find at least half a day per week to continue writing new refactorings and improving the existing code. One idea I originally had with the refactoring library hasn’t played out yet: getting others to create new refactorings. It’s really not that hard! So give it a try if you have an idea for a refactoring you want to automate.

Besides working on the refactoring library, I also really want to get back to writing for InfoQ. Speaking of InfoQ, I’m looking forward to QCon London in March!

Now, enough with the blogging – there are some bugs in Organize Imports I need to fix A happy new year to all of you!

My talk will of course be on the Scala IDE for Eclipse:

This talk introduces the Scala IDE for Eclipse, the obvious choice for all Eclipse users who want to write Scala code. We are going to both take a look at the features the IDE currently provides as well as a glance under the hood.

So if you’re at ESE and want to know more about the Scala IDE for Eclipse, visit me on Thursday, just before lunch.

The project also has a new home at scala-refactoring.org, where you can find more about the refactorings I implemented, how they can be used, etc. I also recommend reading my report, but if you just want an overview, take a look at the poster:

The next steps for me now are to go on holidays, so please excuse if I don’t respond for a week.

And don’t forget to take a look at the other talks.

Buchminster looks rather complex to me, so I went with Maven, even though I had no prior experience with it. Now, a few hours later, I have a Hello World plug-in written in Scala and a bunch of poms that build everything I want, even an update site!

Tycho needs Maven 3, which hasn’t been released yet, so I downloaded the latest alpha build and created an alias that pointed to the mvn binary.

I started with Mattias Holmqvist’s Blog where he explains how to create the initial Maven configuration and an OSGi bundle in Eclipse (I created a Hello World Plug-in Project). Now, we don’t want to have a Java plug-in but one written in Scala, so I added the Scala Nature to the project and re-wrote the two generated files in Scala.

To add Scala functionality to my pom, I followed the Eclipse Scala Maven Integration wiki. I also had to add the Scala Eclipse Plug-in nightly build update site to my list of repositories so Maven could resolve the scala.library dependency the project has.

    <repository>
       <id>scala eclipse nightly</id>
       <layout>p2</layout>
       <url>http://www.scala-lang.org/scala-eclipse-plugin-nightly</url>
    </repository>

Because I apparently didn’t follow Maven’s source layout, I had to explicitly specify the source directory via:

<sourceDirectory>${basedir}/src</sourceDirectory>

Adding the update site and feature projects was a peace of cake when following this tutorial (scroll to Creating an Update Site / P2 repository) from the Tycho project.

I’ve put the whole project on GitHub so you can try it yourself. And remember, this is my first day with Maven, so if I could make the poms even smaller or more idiomatic, please tell me. Or even better, just fork my code!

Next I’m going to find out how to run unit tests and how the integration in Hudson works, and then I can migrate the Scala Refactoring project and delete a build.xml file.

Today, I’m going to show you how you can implement your very own automated refactoring for Scala. “Implement a refactoring you say? But I don’t use IDE xy!”. Don’t worry, you won’t have to use a specific IDE, in fact, you don’t need to use an IDE at all.

Why should you want to write a refactoring? IDEs usually provide a bunch of general refactorings and code generators, but maybe you need a framework or project specific one that no IDE will implement for you. And don’t worry, it is not as complicated as it might sound. (And I should add that when I write refactoring, this includes all program transformations that affect the source code, so you could also create a transformation that just creates new code.)

A refactoring is essentially a transformation of the program in its tree form. Unfortunately, our programs are stored in plain text files, so the transformed tree has to be converted back to text, and this without losing all our pretty formatting. One of the design goals of the Scala Refactoring library was to separate these two concerns as good as possible, so that the implementor (you!) of a refactoring can concentrate on transforming trees and let the library do all the ugly code generation for him. To make it easier for those who already know the Scala compiler’s abstract syntax tree, the refactorings are completely based on this AST instead of introducing a new program representation. I can’t introduce Scala’s AST in detail here, but there’s an introduction in my term project’s technical report which I also plan to expand in my master’s thesis (please give me feedback if you notice any errors).

Please continue reading the rest of the post on my project wiki (where the layout is much more suited for source code).

What has been achieved so far? After investigating the Scala compiler (nothing is more fun than learning a new language by reading it compiler’s source code, trust me), I started to create with a foundation to build the refactorings on. Refactorings basically just transform an AST, which has to be converted back to plain text afterwards (which is far more complicated than it sounds, trust me). This occupied me for the larger part of the project, and it still isn’t finished, but I was able to come up with a scheme that allowed me to leave it in an unfinished state and still being able to perform refactorings, at least good enough for a proof-of-concept.

The implemented refactoring is Extract Method; a perfect candidate because it is not too simple (with regards to the code transformatioms) and it looks much more impressive than e.g. Rename. Is it already usable? I’m not sure, it has not been tested with a lot of real world code (and usually when I did, it didn’t take me long to find new bugs, or rather things that were not yet implemented), but that will certainly be done in the near future. Another hurdle to using it is that you would need to install my modified Eclipse Scala plug-in (and I haven’t yet been able to create a working nightly-build including the Eclipse plug-in and all my stuff that would be needed).

For the near future, i.e. before the thesis, the plan is to implement organize imports, so I can bribe Miles Sabin into including the refactoring library in the Eclipse Scala IDE. After that, I’ll continue the project with a 20 week full-time thesis (~800 hours of work), where I hope to stabilize the existing Extract Method, advance the library so it can be used by other developers without knowing the inner workings of it, and to provide many new refactorings!

In the mean time, I highly appreciate any feedback. And keep an eye on this blog or follow me on twitter to hear the latest about the project.

class Demo1 {
  def demo1(i: Int): Int = {
    val a = i
    val b = a + i
    b
  }
}

Select the line with the assignment to b, murmur the incantation press some keys, et voilà:

class Demo1 {
  def newMethod(i: Int, a: Int): Int = {
    val b = a + i
    b
  }
  def demo1(i: Int): Int = {
    val a = i
    val b = newMethod(i, a)
    b
  }
}

It also works with multiple return values and when passing functions. Now, the code isn’t ready yet, and I have to concentrate on writing my report right now, so it might take a couple more weeks until I can ship something.