Detecting and Naming Boolean Parameters

After a recent discussion on the Scala-Internals mailing list on the pros and cons of methods that take boolean arguments, the consensus was that they should always be passed as named arguments. The compiler doesn’t enforce this, so it’s up to us IDE and tools developers to provide a solution. The code-analysis branch for the Eclipse Scala IDE can now warn you of such boolean arguments that are passed to Scala methods:

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.


Quickfix to Expand Case-Class Bindings in Pattern Matching

When writing Scala code that involves pattern matching I often work with (nested) case classes and sequences of case classes. I usually start with a simple binding like this

case class Person(firstName: String, lastName: String)

List(Person("Mirko", "Stocker")) match {
  case person :: Nil =>; ...

and then when I need to access members of the matched class convert it to use the extractor:

List(Person("Mirko", "Stocker")) match {
  case Person(firstName, lastName) :: Nil => ...

What’s tedious about that step is that one needs to know how many arguments there are and name all the bindings. But not for much longer! I wrote a quick-fix for the Scala IDE that does this for you:

Ctrl+1 brings up the available quick fixes:

And this is what happens when the binding you’re expanding is used in the pattern’s body:

It also works if you use a typed pattern where the type is a case class:

This feature isn’t in the recently released Milestone 1, but it should be part of the next one (or one of the upcoming nightly builds). Suggestions for a better wording – expand case class binding – are welcome 🙂


Move Class, Object and Trait Refactoring for Scala

After lots of bug fixing and improvements of existing refactorings in the Scala IDE, I took a few days off between Christmas and New Year to finally implement a completely new refactoring: Move Class.

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.

Comments Off on Move Class, Object and Trait Refactoring for Scala
« Older
Newer »