Skip to content

The End of the Ruby Fad?

23
Jan
2008

Well, it’s a new year; and apparently no sooner are the resolutions forgotten and the hangovers behind us then the internet en mass decides that we need a new language.  Ruby was indisputably the hip language of 2006 and 2007.  However, in an opinion shift so sudden as to make one’s head spin, the blogosphere seems to have rebelled against the hype and gone in search of a new mistress.

It seems more and more these days like people just don’t want to hear about Ruby.  Ruby posts to link sites like DZone or Reddit get voted down before they have a chance to see the light of day.  Pointless flames litter the blogs, declaiming Ruby and alternatively crowning Groovy, Scala, Java or even XML in its place.  The sad thing is that no one seems to have found the middle ground yet.

Personally, I’m with Reganwald on this one.  I started coding with Ruby back in 2002 (or was it 2001?  I can’t remember now).  It was actually at the recommendation of some random guy on a forum who said that Ruby was a nice and clean language with a lot of potential.  I was getting pretty tired of Java at that point, so I figured I’d give it a try.  Since then, Ruby has become part of my essential scripting toolset, finding applications everywhere from complex utility scripts, build systems and even hacky dynamic web pages for my server monitoring tools.  Based on the strength of the language, I’ve tried Rails a few times without success.  I mean, honestly which is easier to remember?

link_to :page => ""

…or,

<a href=""></a>

The middle ground is really where Ruby belongs, where it flourishes.  It’s hardly a general-purpose language, so it could never replace Java and company.  With that said, it’s far easier to write an incremental backup script in Ruby than in Java.  And while Ruby may not be suitable for an enterprise level, high-traffic web application, it’s certainly up for some tasks within that application.  It’s also perfect for managing scripting and rapid prototyping against that application infrastructure.  Unfortunately the community as a whole seems either blind to its benefits or blinded by its hype.

It seems like it’s constantly an “all or nothing” attitude with these new languages.  Developers these days fall into two camps: those who have heard the hype and rejected what it stands for, and developers who are totally carried away by the emotion of the fad.  To the former camp, developers who straddle the middle ground are traitors to the cause and just as bad as the hyper fanatics.  But to the fanatics, the moderates are fence riders who refuse to fully embrace their destiny.  In short, it’s the moderates who catch flack from both camps.  Yet ironically, it’s the moderates who seem to be doing useful things with the technology, rather than wasting energy on five minute blog demos and eloquent rebuttals.

So on one hand, I’m glad to see the hype die.  It was frustrating having to deal with yet-another bigoted “Rails Rocks, Java Suxz” rant every time I opened my RSS.  On the flip side, the backlash is equally annoying.  It certainly would be nice to have some balance around here, instead of breaking out the petroleum sulfite every time someone accidentally expresses an opinion.  Perhaps now that the bubble has burst, we’ll finally get to see the popularity of Ruby in its proper place.

Scala for Java Refugees Part 3: Methods and Statics

21
Jan
2008

In this series, we’ve already laid the foundations for Scala’s syntax as well as gotten a feel for how some of its object-oriented constructs work.  We haven’t really looked at any of these subjects in-depth however.  Most of our effort has been focused on high-level, flash bang overviews that just get you tasting your way into the language.  This post will go into greater depth regarding method syntax, touch a bit on scopes and attempt to cover how static members work in Scala.  We will also touch on a few gotchas due to “missing” imperative instructions.

Methods Galore

Scala isn’t called a “functional language” just because it’s Turing complete.  Scala has a very powerful and flexible syntax as it relates to methods, both declaration and invocation.  We’ve already seen some basic samples:

class Person {
  def firstName() = {
    var back:String = ...   // read from a database
    back
  }
}

Fairly straightforward.  But this doesn’t really give you the full picture.  In Java for example, you can create methods with different visibilities, modifiers and (oddly enough) return types.  Does Scala support all of this flexibility?

The answer is a qualified “yes”.  Scala does allow for different visibilities on not just methods, but any members.  For example:

class Person {
  private var name = "Daniel Spiewak"
  val ssn = 1234567890    // public constant field
 
  def firstName() = splitName()(0)   // public method
 
  private def splitName() = name.split(" ")    // private method
 
  protected def guessAge() = {
    import Math._
    round(random * 20)
  }
}

At the risk of going on a tangent, it’s worth pointing out the (seemingly) out of place import statement within the guessAge() method.  I mentioned in the first post that Scala’s import is far more powerful than Java’s.  One of its many charms is imparting to the power to import into a specific scope.  The import statement within guessAge() is much like a Java static import statement which only provides access to the Math members within the guessAge() method.  So we couldn’t just make a call to round() from within the splitName() method.  Rubyists can think of it much like the include statement without all of the hassle (it’s not actually including, it’s importing and so eliminating the need for fully-qualified names).

Scala access modifiers are also quite a bit more powerful than Java’s.  For example, protected by default limits access to only subclasses, unlike Java which also allows access to other classes in the same package.  More importantly though, Scala allows the developer to more explicitly specify the scope of the access modifier.  This is accomplished using the modifier[package] notation.  For example:

package com.codecommit.mypackage
 
class MyClass {
  private[mypackage] def myMethod = "test"
}

In this example, myMethod is access-restricted to both the enclosing class and the enclosing package.  Essentially, this is how the Java-style package private modifier can be emulated using Scala.  The protected modifier also allows such visibility qualifiers.  The one restriction here is that the package specified must be an enclosing package.  In the above example, specifying private[com.codecommit.mypackage] is perfectly valid, but private[scala.collection.immutable] would not be correct.

So with the exception of package-private, visibilities work about the same in Scala as they do in Java, both in syntax and function.  Modifiers are really where things get interesting.  Scala has far fewer method modifiers than Java does, primarily because it doesn’t need so many.  For example, Scala supports the final modifier, but it doesn’t support abstract, native or synchronized:

abstract class Person {
  private var age = 0
 
  def firstName():String
  final def lastName() = "Spiewak"
 
  def incrementAge() = {
    synchronized {
      age += 1
    }
  }
 
  @native
  def hardDriveName():String
}

If we were in Java, we would write the above like this:

public abstract class Person {
    private int age = 0;
 
    public abstract String firstName();
 
    public final String lastName() {
        return "Spiewak";
    }
 
    public synchronized void incrementAge() {
        age += 1;
    }
 
    public native String hardDriveAge();
}

Yes, I know it’s more “Scala-esque” to use actors rather than synchronized(), but one step at a time.

You see how Scala keeps with its theme of making the common things concise?  Think about it, almost every method you declare is public, so why should you have to say so explicitly?  Likewise, it just makes sense that methods without a body should be implicitly abstract (unless they’re native).

One very important type-saving feature that you should see in the example above is that Scala doesn’t force you to declare the return type for your methods.  Once again the type inference mechanism can come into play and the return type will be inferred.  The exception to this is if the method can return at different points in the execution flow (so if it has an explicit return statement).  In this case, Scala forces you to declare the return type to ensure unambiguous behavior.

You should also notice that none of the Scala methods actually include a return statement.  This of course seems odd as judging by the Java translation, lastName() should return a String.  Well it turns out that Scala carries a useful shortcut for method returns: the last statement in an expression, be it a scope, a closure or a method becomes its return value.  This convention is also found in languages like Ruby and Haskell.  This example illustrates:

def name() = {
  val name = new StringBuilder("Daniel")
  name.append(" Spiewak");
  name.toString()
}
 
val s = name()
println(s)    // prints "Daniel Spiewak"

Again, in this example the return type of the method is inferred (as String).  We could just as easily have written the name() method as follows, it just would have been less concise.

def name():String = {
  val name = new StringBuilder("Daniel")
  name.append(" Spiewak");
  return name.toString()
}

This “returnless” form becomes extremely important when dealing with anonymous methods (closures).  Obviously you can’t return from a closure, you can only yield, however the principle is the same.  Since closures are often used to reduce code bulk and make certain algorithms more concise, it only makes sense that their return syntax would be as compact as possible:

val arr = Array(1, 2, 3, 4, 5)
val sum = arr.reduceLeft((a:Int, b:Int) => a + b)
 
println(sum)    // 15

In this example we’re passing an anonymous method to the reduceLeft() method within Array.  This method just calls its parameter function repeatedly for each value pair, passing them as the a and b parameters.  Here’s the key part though: our anonymous method adds the two parameters and yields the result back to reduceLeft().  Again, no return statement (or actually, as a closure it would be yield).  Also, we don’t explicitly specify the return type for the closure, it is inferred from our last (and only) statement.

Method Overriding

A very important concept in object-oriented programming is method overriding, where a subclass redefines a method declared in a superclass.  Java’s syntax looks like this:

public class Fruit {
    public int getWorth() {
        return 5;
    }
}
 
public class Apple extends Fruit {
    @Override
    public int getWorth() {
        return 1;
    }
}

Technically, the @Override annotation is optional, but it’s still good practice to use it.  This gives you the compile-time assurance that you actually are overriding a method from a superclass.  In principle, a method declared in a subclass overrides any method in the superclass declared with the exact same signature.  At first glance this seems great, less syntax right?  The problem is when you start dealing with APIs where you’re uncertain if you got the overriding method signature right.  You could just as easily overload the method rather than overriding it, leading to totally different functionality and sometimes hard-to-trace bugs.  This is where @Override comes in.

Scala actually has a bigger problem with method overriding than just signature verification: multiple inheritance.  Multiple inheritance is when one class inherits from more than one superclass.  C++ had this feature years ago, effectively demonstrating how horrible it can really be.  When Gosling laid out the initial spec for Java, multiple inheritance was one of the things specifically avoided.  This is good for simplicity, but it’s sometimes constraining on the power-end of life.  Interfaces are great and all, but sometimes they just don’t cut it.

The key to avoiding ambiguities in the inheritance hierarchy is explicitly stating that a method must override a superclass method.  If that method has the same signature as a superclass method but doesn’t override it, a compile error is thrown.  Add to that significant ordering in the extends/with clauses, and you get a workable multiple-inheritance scheme.  But I’m getting ahead of myself…

Here’s the Fruit example, translated into Scala:

class Fruit {
  def worth() = 5
}
 
class Apple extends Fruit {
  override def worth() = 1
}

Notice that in Scala, override is actually a keyword.  It is a mandatory method modifier for any method with a signature which conflicts with another method in a superclass.  Thus overriding in Scala isn’t implicit (as in Java, Ruby, C++, etc), but explicitly declared.  This little construct completely solves the problems associated with multiple inheritance in Scala.  We’ll get into traits and multiple inheritance in more detail in a future article.

Often times when you override a method, you need to call back to the superclass method.  A good example of this would be extending a Swing component:

class StrikeLabel(text:String) extends JLabel(text) {
  def this() = this("")
 
  override def paintComponent(g:Graphics):Unit = {
    super.paintComponent(g)
 
    g.setColor(Color.RED)
    g.drawLine(1, getHeight() / 2, getWidth() - 1, getHeight() / 2)
  }
}

This component is just a rack-standard JLabel with a red line drawn through its center.  Not a very useful component, but it demonstrates a pattern we see used a lot in Java: delegating to the superclass implementation.  We don’t want to actually implement all of the logic necessary to paint the text on the Graphics context with the appropriate font and such.  That work has already been done for us in JLabel.  Thus we ask JLabel to paint itself, then paint our StrikeLabel-specific logic on top.

As you see in the example, the syntax for making this superclass delegation is almost precisely the same as it is in Java.  Effectively, super is a special private value (much like this) which contains an internal instance of the superclass.  We can use the value just like super in Java to access methods and values directly on the superclass, bypassing our overriding.

That little bit of extra syntax in the extends clause is how you call to a superclass constructor.  In this case, we’re taking the text parameter passed to the default constructor of the StrikeLabel class and passing it on to the constructor in JLabel.  In Java you do the same thing like this:

public class StrikeLabel extends JLabel {
    public StrikeLabel(String text) {
        super(text);
    }
 
    public StrikeLabel() {
        this("");
    }
}

This may seem just a bit odd at first glance, but actually provides a nice syntactical way to ensure that the call to the super constructor is always the first statement in the constructor.  In Java, this is of course compile-checked, but there’s nothing intuitively obvious in the syntax preventing you from calling to the super constructor farther down in the implementation.  In Scala, calling the super constructor and calling a superclass method implementation are totally different operations, syntactically.  This leads to a more intuitive flow in understanding why one can be invoked arbitrarily and the other must be called prior to anything else.

Scala’s Sort-of Statics

Scala is a very interesting language in that it eschews many of the syntax constructs that developers from a Java background might find essential.  This ranges from little things like flexible constructor overloading, to more complex things like a complete lack of static member support.

So in Java, static members are just normal class members with a different modifier.  They are accessed outside of the context of a proper instance using the classname as a qualifier:

public class Utilities {
    public static final String APP_NAME = "Test App";
 
    public static void loadImages() {
        // ...
    }
 
    public static EntityManager createManager() {
        // ...
    }
}
 
System.out.println(Utilities.APP_NAME);
 
Utilities.loadImages();
EntityManager manager = Utilities.createManager();

Scala does support this type of syntax, but under the surface it is quite a bit different.  For one thing, you don’t use the static modifier.  Instead, you declare all of the “static” members within a special type of class which acts as an only-static container.  This type of class is called object.

object Utilities {
  val APP_NAME = "Test App"
 
  def loadImages() = {
    // ...
  }
 
  def createManager():EntityManager = {
    // ...
  }
}
 
println(Utilities.APP_NAME)
 
Utilities.loadImages()
val manager = Utilities.createManager()

The syntax to use these “statics” is the same, but things are quite a bit different in the implementation.  It turns out that object actually represents a singleton class.  Utilities is in fact both the classname and the value name to access this singleton instance.  Nothing in the example above is static, it just seems like it is due to the way the syntax works.  If we port the above class directly to Java, this is what it might look like:

public class Utilities {
    private static Utilities instance;
 
    public final String APP_NAME = "Test App";
 
    private Utilities() {}
 
    public void loadImages() { 
        // ...
    }
 
    public EntityManager createManager() {
        // ...
    }
 
    public static synchronized Utilities getInstance() {
        if (instance == null) {
            instance = new Utilities();
        }
 
        return instance;
    }
}
 
// ...

So Scala provides a special syntax which basically gives us a singleton for free, without all of the crazy syntax involved in declaring it.  This is a really elegant solution to the problems with proper statics.  Since Scala doesn’t actually have static members, we no longer have to worry about mixing scopes, access qualifiers, etc.  It all just works nicely.

But what about mixing static and instance members?  Java allows us to do this quite easily since static is a qualifier, but Scala requires “static” members to be declared in a special singleton class.  In Java, we can do this:

public class Person {
    public String getName() {
        return "Daniel";
    }
 
    public static Person createPerson() {
        return new Person();
    }
}

The solution in Scala is to declare both an object and a class of the same name, placing the “static” members in the object and the instance members in the class.  To be honest, this seems extremely strange to me and is really the only downside to Scala’s singleton syntax:

object Person {
  def createPerson() = new Person()
}
 
class Person {
  def name() = "Daniel"
}

The syntax for using this object/class combination is exactly the same as it would be in Java had we mixed static and instance members.  The Scala compiler is able to distinguish between references to Person the object and references to Person the class.  For example, the compiler knows that we can’t create a new instance of an object, since it’s a singleton.  Therefore we must be referring to the class Person in the createPerson() method.  Likewise, if a call was made to Person.createPerson(), the compiler is more than capable of deducing that it must be a reference to the object Person as there is no way to access a method directly upon a class.  It’s all perfectly logical and consistent, it just strikes the eye funny when you look at it.

Conclusion

And so ends our two part, whirlwind tour of Scala’s object-oriented constructs, methods and statics.  There are of course trivialities along the way which we haven’t covered, but those are easy enough to learn now that you have the basics.  The more interesting syntax is still to come though.  For one thing, we’ve barely scratched the surface of all of the things that you can do with methods.  They don’t call it a “functional” language for nothing!  But in keeping with our goal to represent the imperative side of the Scala language, we’ll save that for later.

In the next article, we’ll look at pattern matching and exception handling, two (surprisingly) related concepts.

The Benefits of Type Inference

16
Jan
2008

There’s been some complaining around the blogosphere about the use of Scala’s type inference mechanism, how it makes it difficult to know what type you’re dealing with since the only explicit declaration of type could be several steps up the call stack.  This is true.  What is also true (and really more important) is that Scala almost completely eliminates the need to worry about what type you’re dealing with; and it does this without sacrificing the all-important compile-time type checking.

Developers with experience in dynamic languages such as Ruby or Python will know what I mean when I say that there comes a time when you stop worrying about what type a value is and concern yourself more with how you can use it.  For example, when I code in Ruby, I often write code like this:

def operate(v)
  if v < "daniel"
    v += "spiewak"
    return value[0..(v.size - 7)]
  end
 
  v
end

When I wrote this method, I wasn’t necessarily thinking about v as a String, but rather as some value which defined the less-than operator against a String, the + operator again taking a String and the square brackets operator taking a Range.  I also never documented anywhere that this method expects a String.  I probably could document it that way, and many people would do so.  But really, all that needs to be documented is that the value passed to the method defines those three functions.

Scala enables the same sort of “duck typing” but adds static checking.  It has constructs which enable values to be typed based on defined functions and such, but I’m not referring to these.  The feature of Scala which really enables one to almost forget about type is the static type inference.  Without it, not only would the language be far more verbose, but also every algorithm, every function would have to pedantically spell out precisely the type expected in every situation.  This sort of restriction makes algorithms far more rigid and far more difficult to manage in the long run.  This is the reason interfaces are used for everything in Java, to satisfy the compiler just enough to allow an arbitrary type to be passed under the surface.

Think about it.  How many times have you written code to use the java.util.Map interface rather than HashMap directly to avoid strongly coupling yourself to one Map implementation?  In Java, one usually writes code like this:

import java.util.Map;
import java.util.HashMap;
 
public class MapTest {
    private Map<Integer, String> myMap;    // using the interface type
 
    public MapTest() {
        myMap = createMap();
    }
 
    public Map<Integer, String> createMap() {
        return new HashMap<Integer, String>();
    }
}

Granted, needlessly verbose, but not too far off the mark when it comes to Java design patterns.  This code makes it fairly trivial to change the underlying map implementation used throughout the class.  The implementation can even be changed by a subclass if it overrides the createMap() method.

In this code, we’re specifying semantically what sort of operations we need.  We’re being forced to tell the compiler that we want a map, but we’re not particular about what sort of map we get.  In short, we’re typing myMap less strongly than if we used the HashMap type directly.  This sort of “loose typing” is good, because we don’t want to rely on a particular implementation.  Unfortunately, the Java way of implementing this typing has given rise to the ubiquitous use of what I call “the I pattern”.  Just look at the Eclipse RCP hierarchy or virtually any of the classes in the Wicket API.  Almost all of them are typed against their almost-pointless interface definition; IModel for example.

Scala avoids this problem with type inference.  Type inference is inherently “loose typing” because it’s constraining the type based on the value which defines it.  Translating the Java sample into Scala yields the following:

import scala.collection.mutable.HashMap
 
class MapTest {
  var myMap = createMap()
 
  def createMap() = new HashMap[Int, String]
}

The myMap variable is actually of type HashMap, and the compiler knows and enforces this.  However, we can change the return value from createMap() and it will be immediately reflected in the type of myMap.  Thus there is no need to type the variable against its superinterface, since the flexibility we want is already available through type inference.

The only thing we do need to worry about here is not using any methods which are specific to HashMap.  Once we do that, we’ll have to actually change our code in more than one place if we want to change the map implementation.  However, when’s the last time you used any function that was specific to a collection implementation?

The point of the original article is actually that type inference makes it harder to see what type your variable (or even your method) is going to be, since the only explicit declaration of type is tucked away out of sight.  This is true.  In the above example, to know what type myMap is, we need to remember that createMap() actually returns a HashMap[Int, String] value.  The point I’m trying to make though is that worrying about precisely what type each variable may be is the wrong approach.  All you need to know is what they can do, and this is something which is easy enough to handle.

So does type inference make you do more work than necessary: yes, but only if you’re so rigidly dogmatic in your mind-set that you can’t accept the fact that it doesn’t matter.  To those of you who have an aversion to this sort of pattern: deal with it (you’ll thank me later).

Scala for Java Refugees Part 2: Basic OOP

14
Jan
2008

In the previous installment, we looked at the basics of Scala syntax and provided some simple conceptual explanations.  Obviously there’s a lot more to this language than what I was able to present in a single (albeit very long) article.  In this post we’re going to examine Scala’s object oriented constructs (classes, objects, methods, etc) and how they compare to Java.

A More Complex Example

package com.codecommit.examples
 
import java.awt.{Color, Graphics}
 
abstract class Shape {
  var fillColor:Color = null
 
  def draw(g:Graphics):Unit
  def area:Double
}
 
class Circle(var radius:Int) extends Shape {
  def draw(g:Graphics):Unit = {
    if (fillColor == null) {
      g.drawOval(0, 0, radius / 2, radius / 2)
    } else {
      g.setColor(fillColor);
      g.fillOval(0, 0, radius / 2, radius / 2)
    }
  }
 
  def area:Double = {
    var back = Math.Pi * radius 
    back * radius
  }
}
 
class Square(var width:Int) extends Shape {
  def draw(g:Graphics):Unit = {
    if (fillColor == null) {
      g.drawRect(0, 0, width, width)
    } else {
      g.setColor(fillColor)
      g.fillRect(0, 0, width, width)
    }
  }
 
  def area:Double = width * width
}

Remember that Scala does not require every public class to be declared in a file of the same name.  In fact, it doesn’t even require every class to be declared in a separate file.  Organizationally, it makes sense for all of these trivial classes to be contained within the same file.  With that in mind, we can copy/paste the entire code snippet above into a new file called “shapes.scala”.

The first thing you should notice about this snippet is the package declaration.  All of these classes are declared to be within the “com.codecommit.examples” package.  If this were Java, we’d have to create a new directory hierarchy to match (com/codecommit/examples/).  Fortunately, Scala saves us work here as well.  We can just store this file right in the root of our project and compile it in place, no hassle necessary.

With that said, it’s still best-practice to separate your packages off into their own directories.  This organization makes things easier to find and eases the burden on you (the developer) in the long run.  And after all, isn’t that what we’re trying to do by looking at Scala in the first place?

To compile this class, we’re going to use the fsc command (short for Fast Scala Compiler).  FSC is one of those brilliant and obvious Scala innovations which allows repeated compilation of Scala files with almost no latency.  FSC almost completely eliminates the compiler startup time incurred by the fact that the Scala compiler runs on the JVM.  It does this by “warm starting” the compiler each time, keeping the process persistent behind the scenes.  Effectively, it’s a compiler daemon, sitting in the background and using almost no resources until called upon.  The command syntax is identical to the scalac command:

fsc -d bin src/com/codecommit/examples/*.scala

This command will compile all of the .scala files within the src/com/codecommit/examples/ directory and place the resultant .class files into bin/.  Experienced Java developers will know the value of this convention, especially on a larger project.  Once again, Scala doesn’t intend to upset all best-practices and conventions established over decades.  Rather, its purpose is to make it easier to do your job by staying out of the way.

First Impressions

Of course, compiling an example doesn’t do us much good if we don’t understand what it means.  Starting from the top, we declare the package for all of the classes within the same file.  Immediately following is a single statement which imports the java.awt.Color and java.awt.Graphics classes.  Notice Scala’s powerful import syntax which allows for greater control over individual imports.  If we wanted to import the entire java.awt package, the statement would look like this:

import java.awt._

In Scala, the _ character is a wildcard.  In the case of an import it means precisely the same thing as the * character in Java:

import java.awt.*;

Scala is more consistent than Java however in that the _ character also serves as a wildcard in other areas, such as type parameters and pattern matching.  But I digress…

Looking further into the code sample, the first declaration is an abstract class, Shape.  It’s worth noting here that the order of declarations in a file does not hold any significance.  Thus, Shape could just as easily have been declared below Circle and Rectangle without changing the meaning of the code.  This stands in sharp contrast to Ruby’s syntax, which can lead to odd scenarios such as errors due to classes referencing other classes which haven’t been declared yet.  Order is also insignificant for method declarations.  As in Java, a method can call to another method even if it is declared above the delegate.

class Person {
  def name() = firstName() + ' ' + lastName()
 
  def firstName() = "Daniel"
  def lastName() = "Spiewak"
}

Properties

Returning to our primary example, the first thing we see when we look at class Shape is the color variable.  This is a public variable (remember, Scala elements are public by default) of type Color with a default value of null.  Now if you’re a Java developer with any experience at all, warning sirens are probably clanging like mad at the sight of a public variable.  In Java (as in other object-oriented languages), best practice says to make all fields private and provide accessors and mutators.  This is to promote encapsulation, a concept critical to object oriented design.

Scala supports such encapsulation as well, but its syntax is considerably less verbose than Java’s.  Effectively, all public variables become instance properties.  You can imagine it as if there were mutator and accessor methods being auto-generated for the variable.  It’s as if these two Java snippets were equivalent (the analog is not precise, it just gives the rough idea):

public class Person {
    public String name;
}

public class Person {
    private String name;
 
    public String getName() {
        return name;
    }
 
    public void setName(String name) {
        this.name = name;
    }
}

It’s not quite like that, but you get the point of the example.  What’s really happening is we’re taking advantage of the fact that in Scala, variables are actually functions.  It’s a bit of an odd concept to wrap your head around coming from an imperative background, so it’s probably easier just to keep thinking of variables as variables.

Let’s imagine that we’ve got our Shape class and its public variable fillColor.  Down the road we decide that we need to add a check to the mutator to ensure that the color is never red (why, I’m really not sure, but we do).  In Java, this would be impossible because the variable is public and forcing the use of a mutator would change the public class signature.  Thankfully, Scala allows us to easily rewrite that portion of the class without affecting the class signature or any code which actually uses the class:

abstract class Shape {
  private var theFillColor:Color = null
 
  def fillColor = theFillColor
 
  def fillColor_=(fillColor:Color) = {
    if (!fillColor.equals(Color.RED)) {
      theFillColor = fillColor
    } else {
      throw new IllegalArgumentException("Color cannot be red")
    }
  }
}
 
var shape = ...
shape.fillColor = Color.BLUE
var color = shape.fillColor
 
shape.fillColor = Color.RED  // throws IllegalArgumentException

As you can see, the _= method suffix is a bit of magic syntax which allows us to redefine the assignment operator (effectively) for a variable.  Notice from the perspective of the code using Shape, it still looks like a public field.  The code snippet using Shape will work with both the previous and the modified versions of the class.  Think of it, no more get* and set*…  Now you can use public fields with impunity and without fear of design reprisal down the road.

Just to ensure this point is really clear, here’s the analog of the syntax in Ruby:

class Shape
  def initialize
    @fill_color = nil
  end
 
  def fill_color
    @fill_color
  end
 
  def fill_color=(color)
    raise "Color cannot be red" if color == Color::RED
 
    @fill_color = color
  end
end

This obvious difference being that the Scala example will be type-checked by the compiler, while the Ruby code will not.  This is one of the many areas where Scala demonstrates all the flexibility of Ruby’s syntax coupled with the power and security of Java.

Abstract Methods

One of the important features of the Shape class in the example is that it’s declared to be abstract.  Abstract classes are very important in object oriented design, and Scala wouldn’t be much of an object oriented language if it didn’t support them.  However, looking through the definition of the class, there do not seem to be any abstract methods declared.  Of course, as in Java this is perfectly legal (declaring an abstract class without abstract members), it just doesn’t seem all that useful.

Actually, there are two abstract methods in the Shape class.  You’ll notice that neither the draw nor the area methods are actually defined (there is no method body).  Scala detects this and implicitly makes the method abstract.  This is very similar to the C++ syntax for declaring abstract methods:

class Shape {
public:
    virtual void draw(Graphics *g2) = 0;
    virtual double area() const = 0;
 
    Color *fillColor;
};

Thankfully, this is the end of Scala’s similarity to C++ in the area of abstract types.  In C++, if a class inherits from an abstract base class and fails to implement all of the inherited abstract methods, the derived class implicitly becomes abstract.  If such a situation occurs in Scala, a compiler error will be raised informing the developer (as in Java).  The only exception to this rule are case classes, which are weird enough to begin with and will require further explanation down the road.

Constructors

Despite the best efforts of Josh Bloch, the constructor lives on in the modern object-oriented architecture.  I personally can’t imagine writing a non-trivial class which lacked this virtually essential element.  Now, it may not have been immediately obvious, but all of the Scala classes shown in this post have a constructor.  In fact, every class (and object) has at least one constructor.  Not just a compiler-generated default mind you, but an actually declared in-your-code constructor.  Scala constructors are a bit different than those in Java, which are really just special methods named after the enclosing class:

public class Person {
    public Person(int age) {
        if (age > 21) {
            System.out.println("Over drinking age in the US");
        } 
    }
 
    public void dance() { ... }
}
 
Person p = new Person(26);   // prints notice that person is overage

In Scala, things are done a bit differently.  The constructor isn’t a special method syntactically, it is the body of the class itself.  The above sample is equivalent to the following bit of Scala code:

class Person(age:Int) {
  if (age > 21) {
    println("Over drinking age in the US")
  }
 
  def dance() = { ... }
}
 
var p = new Person(26)   // prints notice that person is over-age

Remember the first Scala example I listed in this series?  (the three line HelloWorld)  In this code, the body of the “main method” is implemented as a constructor in the HelloWorld object.  Thusly:

object HelloWorld extends Application {
  println("Hello, World!")
}

The println statement isn’t contained within a main method of any sort, it’s actually part of the constructor for the HelloWorld object (more on objects in a later post).  Any statement declared at the class level is considered to be part of the default constructor.  The exceptions to this are method declarations, which are part of the class itself.  This is to allow forward-referencing method calls:

class ChiefCallingMethod {
  private var i = 1
 
  if (i < 5) {
    lessFive(i)
  }
 
  def lessFive(value:Int) = println(value + " is less than 5")
}
 
var chief = new ChiefCallingMethod()

This code will run and successfully determine that 1 is indeed less than 5, once again proving the trustworthiness of mathematics.

This constructor syntax seems very strange to those of us accustomed to Java.  If you’re like me, the first thought which comes into your head is: how do I overload constructors?  Well, Scala does allow this, with a few caveats:

class Person(age:Int) {
  if (age > 21) {
    println("Over drinking age in the US")
  }
 
  def this() = {
    this(18)
    println("Created an 18 year old by default")
  }
 
  def dance() = { ... }
}

This revised Person now has two constructors, one which takes an Int and one which takes no parameters at all.  The major caveat here is that all overloaded constructors must delegate to the default constructor (the one declared as part of the class name).  Thus it is not possible to overload a constructor to perform entirely different operations than the default constructor.  This makes sense from a design standpoint (when was the last time you declared such constructors anyway?) but it’s still a little constraining.

Constructor Properties

So you understand Scala constructors and you’re getting the feel for public instance properties, now it’s time to merge the two concepts in constructor properties.  What are constructor properties?  The answer has to do with a (seemingly) odd bit of Scala syntax trivia, which says that all constructor parameters become private instance vals (constants).  Thus you can access constructor parameter values from within methods:

class Person(age:Int) {
  def isOverAge = age > 21
}

This code compiles and runs exactly as expected.  It’s important to remember that age isn’t really a variable (it’s a value) and so it cannot be reassigned anywhere in the class.  However, it might make sense to change a person’s age.  After all, people do (unfortunately) grow older.  Supporting this is surprisingly easy:

class Person(var age:Int) {     // notice the "var" modifier
  def isOverAge = age > 21
 
  def grow() = {
    age += 1
  }
}

In this code, age is no longer just a private value, it is now a public variable (just like fillColor in Shape).  You can see how this can be an extremely powerful bit of syntax when dealing with simple bean classes:

class Complex(var a:Int, var b:Int)
 
// ...
val number = new Complex(1, 0)
number.b = 12

Omission of the curly braces is valid syntax in Scala for classes which do not require a body.  This is similar to how Java allows the omission of braces for single line if statements and so on.  The roughly equivalent Java code would be as follows:

public class Complex {
    private int a, b;
 
    public Complex(int a, int b) {
        this.a = a;
        this.b = b;
    }
 
    public int getA() {
        return a;
    }
 
    public void setA(int a) {
        this.a = a;
    }
 
    public int getB() {
        return b;
    }
 
    public void setB(int b) {
        this.b = b;
    }
}
 
// ...
final Complex number = new Complex(1, 0);
number.setB(12);

Much more verbose, much less intuitive, and far less maintainable.  With the Scala example, adding another property is as simple as adding a parameter to the constructor.  In Java, we have to add a private field, add the getter, the setter and then finally add the extra parameter to the constructor with the corresponding code to intialize the field value.  Starting to see how much code this could save you?

In our code sample way up at the top of the page, Circle declares a property, radius (which is a variable, and so subject to change by code which uses the class).  Likewise Square has a property, width.  These are constructor properties, and they’re about the most cruft-saving device in the entire Scala language.  It’s really amazing just how useful these things are.

Conclusion

We’ve really just scratched the surface of all that Scala is able to accomplish in the object-oriented arena.  The power of its constructs and the elegance of its terse syntax allows for far greater productivity, especially when dealing with a larger project.  Moreover, Scala’s object oriented capabilities prove that it’s not just an interesting functional language for pasty academics but a powerful, expressive and practical language well suited to almost any real-world application.

Coming up: more on methods (including overriding) and a rundown on static members.

Quick Explanation of Scala’s (_+_) Syntax

9
Jan
2008

It seems every time I turn around, someone else is railing against Scala for having an enormously cryptic syntax, citing (_+_) as an example.  Aside from fact that it looks like an upside-down face, I think this little construct is probably catching more flack than it deserves.  To start with, let’s get a bit of a context:

val numbers = Array(1, 2, 3, 4, 5)
val sum = numbers.reduceLeft[Int](_+_)
 
println("The sum of the numbers one through five is " + sum)

Block out the second line for just one second.  The example is really pretty understandable.  The first line creates a new value (not a variable, so it’s constant) of inferred type Array[Int] and populating it with the results from the factory method Array.apply[T](*T)  (creates a new array for the given values).  The correspondent to the example in Java would be something like this:

final int[] numbers = {1, 2, 3, 4, 5};
int sum = 0;
for (int num : numbers) {
    sum += num;
}
 
System.out.println("The sum of the numbers from one to five is " + sum);

You’re probably already getting a bit of an idea on the meaning behind that magic (_+_) syntax.  Let’s go a bit deeper…

In Scala, arrays, lists, buffers, maps and so on all mixin from the Iterable trait.  This trait defines a number of methods (such as foreach) which are common to all such classes.  This is precisely why the syntax for iterating over an array is the same as the syntax for iterating over a list.  One of the methods defined in this trait is the high-order function reduceLeft.  This method essentially iterates over each sequential pair of values in the array and uses a function parameter to combine the values in some way.  This process is repeated recursively until only a single value remains, which is returned.

Linearized, the function looks something like this:

val numbers = Array(1, 2, 3, 4, 5)
var sum = numbers(0)
sum += numbers(1)
sum += numbers(2)
sum += numbers(3)
sum += numbers(4)

I mentioned that reduceLeft uses a function parameter to perform the actual operation, and this is where the (_+_) syntax comes into play.  Obviously such an operation would be less useful if it hard-coded addition as the method for combination, thus the function parameter.  You’ll find this is a common theme throughout the Scala core libraries: using function parameters to define discrete, repeated operations so as to make generic functions more flexible.  This pattern is also quite common in the C++ STL algorithms library.

(_+_) is actually a Scala shorthand for an anonymous function taking two parameters and returning the result obtained by invoking the + operator on the first passing the second.  Less precisely: it’s addition.  Likewise, (_*_) would define multiplication.  With this in mind, we can rewrite our first example to use an explicitly defined closure, rather than the shorthand syntax:

val numbers = Array(1, 2, 3, 4, 5)
val sum = numbers.reduceLeft((a:Int, b:Int) => a + b)
 
println("The sum of the numbers one through five is " + sum)

The examples are functionally equivalent.  The main advantage to this form is clarity.  Also, because we’re now explicitly defining the anonymous function, we no longer need to specify the type parameter for the reduceLeft method (it can be inferred by the compiler).  The disadvantage is that we’ve added an extra 20 characters and muddied our otherwise clean code snippet.

Another bit that is worth clarifying is that Scala does not limit this syntax to the addition operator.  For example, we could just as easily rewrite the example to reduce to the factorial of the array:

val numbers = Array(1, 2, 3, 4, 5)
val prod = numbers.reduceLeft[Int](_*_)
 
println("The factorial of five is " + prod)

Notice we have changed the (_+_) construct to (_*_)  This is all that is required to change our reduction operation from a summation to a factorial.  Let’s see Java match that!

Admittedly, the underscore syntax in Scala is a rather odd looking construct at first glance.  But once you get used to it, you can apply it to many complex and otherwise verbose operations without sacrificing clarity.  In fact, the only thing you sacrifice by using this syntax is your intern’s ability to read and modify your code; and really, is that such a bad thing to be rid of?  :-)