The warning comes with a quick-fix that inserts the parameter name:

Of course, the competition isn’t sleeping either, the IntelliJ Scala plug-in just got a bunch of new Intentions.

Move Class (see Fowler’s description if you’re unfamiliar with it) moves a top-level Class, Object or Trait definition into a different package. And if there exists more than one declaration in the file, you can choose to split-off one of the declarations or to move them all. The refactoring will move all the necessary imports along, and also update all the references to the moved implementation (other imports, or qualified names) in the project.

The refactoring can either be invoked from the menu, or by drag-and-dropping a file in the Package Explorer. Here are some screenshots of the refactoring in action:

It’s also possible to create a new package during the refactoring:

As usual, the changes can be previewed. In this case, the class is removed from the original source file and an import is added to its new location:

Looking at the created file, we see the changed package declaration (a copyright notice in the original file would also have been copied along to the new file) and some imports to types of the originating package:

There are a few limitations: the refactoring works only on Scala code, and it simply ignores visibility issues, so moving might result in compilation errors (cursory tests showed that this also happens in Eclipse JDT — my gold standard for refactoring implementations).

The Move refactoring will be part of the 2.1 release of the Scala IDE, for which there are nightly builds available.

Sourcecloud is an Eclipse plug-in that lets you create tag clouds of your source code. The idea for this project came from Kevlin Henney, who used such tag clouds in a presentation at Jazoon 2010 (if I remember correctly). Luckily for me, Cloudio comes with an example application, from which I was able to reuse most of the parts, so all the credits go to Cloudio’s creator Stephan Schwiebert.

Why would you want to make tag clouds for source code? It can give you a quick first impression of the quality of a code base. Ideally, you should see many names of the project’s domain. On the other hand, if you see lots of nulls, ints and Strings, chances are that the code will be hard to understand because there are not many domain specific types in it.

You can install Sourcecloud from the update site for integration builds into Eclipse Indigo. And here’s how the result looks:

And here’s a screenshot of the Eclipse view:

The source code is on GitHub, so if you want to add or change something, fork it and send me a pull request!

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.

Multiple Desktops

A bug that I observe almost every time I start Eclipse is Bug Nr. 98540, Eclipse shells open on different desktops (created in 2005). The problem is:

I launch the Eclipse process on one desktop, and then switch to another. The splash shell opens on the second desktop, not the one from which it was launched.

If you’re not using multiple desktops, this might not sound like a huge problem, but I can tell you, it’s really annoying if Eclipse just follows you around and doesn’t stay on the desktop it belongs to. This is not restricted to starting the initial Eclipse instance but also happens when you’re developing plugins and launch a new workspace.

Global Preferences

There are certain preferences I want in all my Eclipse instances, for example the “Show Heap Status”, or the Font of the editor. So it would be really nice if there were something like global preferences that can be saved somewhere and are then used by all workspaces. It’s already possible to manually import and export preferences, so you can share preferences, but doing it manually is tedious.

Another interesting project going into a similar direction is Google’s Workspace Mechanic. A bug report also exists since 2005.

Unnecessary Scrollbars Shown

The following screenshot should make the problem obvious:

Why are there scrollbars shown? I don’t use any other GTK programs, so this might be a GTK problem; but it still annoys me from time to time. And there’s a bug report for it since 2002.

Despite all these problems, I’m still a very happy Eclipse user and developer, so congratulations for this otherwise great release!

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.