Cleaning up “Multiple Returns” in Scala

Here’s a little titbit from GridGain’s Scalar DSL code:

Not frequently – but often enough – we have the following code in Scala:

def func() {
    if (this) {
        doThat()
        
        return
    }
    ...
    if (that) {
        doThis()
        
        return
    }
    ...
}

You get the picture… It’s not kosher to put the code like that into Scala compiler 🙂 Now, in some cases the algo can be rework to remove multiple returns, but in other cases this simply isn’t possible without unnecessary complicating the code. In other words, trade offs are not worth it.

So, for case where algo can’t be changed we’ve come up with a simple “cleaning” solution in a way of a “pimp” for Unit type using Scala’s scala.util.control.Break support:

implicit def f(v: Unit) = new { def ^^ = break }

Once you have that “pimp” in the scope you can rewrite previous example like this:

def func() = breakable {
    if (this) doThat() ^^
    ...
    if (that) doThis() ^^        
    ...
}

Few comments:

  • Operator ^^ has a nice visual connotation of exiting the function and code gets shorter which never hurts.
  • ^^ is also unique enough so that unlikely naming conflicts won’t confuse the compiler.
  • It enables user-defined scopes while simple return always defaults to the scope of the entire method.

This is, of course, more of a “’cause I can” type of the solution but nonetheless represents great flexibility of the Scala language.

Enojy!

4 responses

  1. Nikita, so I’m familiar with implicits in scala, but in this case, is the implicit conversion triggered based on the Unit return type of doThis(), doThat()? You couldn’t for example just say this:

    if (this) ^^

    Am I wrong? Sorry, don’t have my env set up now to try it out.

    Another comment, which is more of an opinion, is that I’m not sure how I feel about the ability to utilize operators as methods, though creating DSLs. It’s definitely flexible, which I like, but it seems that if abused, which seems to be the case in many DSLs, it’s more detrimental than beneficial, at least from readability standpoint. Just look at Lift. I think it’s a great framework, but the abuse of operator DSL is very evident. Looking at something even as simple as url mappings, makes your eyes pop out. It’s made simpler with a great IDE of course, as all is strongly typed and type inference is great, but what about us that occasionally still use emacs 🙂

  2. Ilya,
    It was more of a tongue in cheek post 🙂 I’m not saying we should all jump into ‘^^’ but rather show how Scala is flexible when you need it – shown on a bit silly example.

    Best,
    Nikita.

  3. Since the outer method is already returning unit, and the method calls are returning unit, couldn’t you just as easily change that to:

    def func(){
    if (this) return doThat()
    if (that) return doThis()
    }

    and avoid the implicit, and use of breakable?

    Or am I missing some other point you are trying to make?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: