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.

What follows is my project proposal for my master term project (12 ECTS, ~360 hours of work, the same as a bachelor thesis actually). The project starts next week and will keep my busy for the next 14 weeks.

If Scala wants to succeed Java, it needs strong IDE support, and this includes automated refactorings. Although studies show that refactoring tools are underused, they still serve as a strong selling point to convince programmers to use an IDE (or even a whole language) over a simple text editor. Several Scala IDEs are under development, but all of them lack extensive support for refactoring.

I’ve worked on various projects implementing (Ruby, C++) and supervising (JavaScript, Groovy) refactoring tools. Taking advantage of these experiences, I believe that a sound refactoring engine can be built for Scala in due time.

Objectives

Scala should get an IDE independent facility to perform refactorings. This API can then be used by all IDEs and other tools to refactor Scala code – fostering collaboration to get truly great refactoring capabilities instead of several half-baked implementations from competing IDEs (as the situation with other languages – e.g. Ruby – is today).

The basis to create a successful tool is the code manipulation strategy, i.e. how the source is modified, and most important, how the changed source is obtained (formatting, comments, white-space). In the past, we at the Institute for Software experimented with different strategies but have yet to come up with a silver bullet. Therefore, the first focus of this project will be to analyze existing ways and to come up with a suitable code representation for this project. Additionally, Scala’s functional aspects (especially pattern matching) should lend itself ideally to the manipulation of tree-like data-structures.

Finally, to make the implementation of refactorings easier, several granularities of abstractions will be needed. Basic building blocks to modify the source trees (e.g. ‘move x to y’, ‘rename x to y’, ‘create a new X at y’) can then be assembled to complete refactorings (“cursor position is x, rename all references to ‘y’”) and exposed together with – probably already existing – query-operations (‘what can be renamed’, ‘what is located at the current cursor position’) and feedback (warnings, errors) through the API. The result of such a refactoring operation will be a set of diffs the IDE can then apply and show to the user.

Vision

To my knowledge there exists no language that has IDE independent refactoring support, and the only people creating new refactorings are the developers of the IDE. If this project succeeds, Scala will have a simple API to manipulate its source code on which refactorings and other code manipulation tools (e.g. quick fixes, code generators) can be built by Scala programmers and not only IDE adepts.

Desired Results

An API to do refactoring together with an implementation and ideally two reference users in the form of automated tests and an Eclipse plug-in. Whether these goals are realistic will be determined during the project and adapted if necessary. A more detailed project plan will be developed in the first week of the project, as soon as the effort can be better estimated with regards to the available environment (e.g. the richness and suitability of the AST).

Now, what do you think? How important is automated refactoring support for you in choosing an IDE or a language?

After almost 4 years of blogging at blog.misto.ch, I needed a change. The posting frequency constantly dropped and I’ve picked up twitter to post shorter messages, and most of the serious work I did ended up on InfoQ.

So, why even bother blogging anymore? Well, I’ll soon start my masters project and I want to have a platform to communicate about it¹. I also feel (or rather hope) that this might interest a broader audience, thus the switch over to english and – in the wake of all these changes – also a fresh design²³.

And now, some rules for this blog:

1. Comments are to be written in English or they’ll get deleted.
2. You may criticize my English (I’m all for improving my skills), but please only if you’re really sure and can back up your claim.
3. Subscribe to the feed!

1. If you’re curious, and as you’ve probably already guessed, I’ll bring automated refactoring support to Scala! But more on that in the following days.
2. That, as I just realized today, also matches the color scheme of our bathroom.
3. Aren’t these footnotes pretty?