Main

January 24, 2010

Applying scala to solving real world problems: Say bye bye to boring constructors and getters/setters

In Java, it is very common and boring to create constructors and getters/setters like:

public class Foo {
  private String x;
  private String y;

  public Foo(String x, String y) {
    this.x = x;
    this.y = y;
  }
  public String getX() {
    return x;
  }
  public String getY() {
    return y;
  }
  public void setX(String x) {
    this.x=x;
  }
  public void setY(String y) {
    this.y=y;
  }
}

Yes, Eclipse provides the "Generate constructor using fields" and "Generate getters and setters" commands to do that, but it is still very boring and requires work from us. In Scala, all this boring work is no longer required:

class Foo(x: String, y: String) {
}

Due to the closure support, x and y will be available to all methods inside the Foo class just like Java fields:

class Foo(x: String, y: String) {
  def someMethod {
    println(x+y)
  }
}

To create getters, use to the "val" keyword:

class Foo(val x: String, val y: String) {
  ...
}

The Scala compile will create a getter methods named "x" and "y" automatically. To create setters in addition to getters, use "var" instead of "val":

class Foo(var x: String, var y: String) {
  ...
}

Then the compiler will create setter methods named "x =" and "y =" for you (Yes, the method name contains a space and then an equal sign, which are allowed in Scala). To call the getters and setters, you may:

val f = new Foo("a", "b")
f.x            //In Scala you don't need to use () to call a method
f.x = ("c")  //This is OK
f.x = "c"    //Again, don't have to use ()

Pretty neat, isn't it?

October 09, 2007

Applying scala to solving real world problems

Scala is no doubt an excellent language. However, problems like 8-queen or quick sort in the scala doc just aren't  convincing to software professionals in the industry. So I'd like to show how to apply it to solving real world problems in Java. Here let's consider the logging problem in Java. Usually people write code like:

        if (log.isDebugEnabled())
        {
            log.debug("Foo is: " + foo);
        }

Why check isDebugEnabled() if the log object will not log the message if debug is not enabled? This is for performance. If we didn't have this check, the toString() would always be called on foo and the result would always be appended to "Foo is:" to form a new string, even when debug was not enabled.

Scala can easily solve this problem using called-by-name parameters:

class Log {
  var isDebugEnabled: Boolean = false;
 
  def debug(msg: => String) {  //msg is a string expression that is unevaluated
    if (isDebugEnabled) {
      System.out.println(msg); //evaluate msg as if it is a function
    }
  }
}

Now you call this method and provide an expression and it won't be evaluated unless debug is enabled:

    val log: Log = new Log();
    var foo: Int = 123;
    log.debug("Foo is:"+foo); //won't be evaluated
    log.isDebugEnabled = true;
    log.debug("Foo is:"+foo); //will be evaluated inside the debug() method