5.2 Day 1: The Castle on the Hill

In Edward Scissorhands, there’s a castle on a hill that is, well, a little different. In a bygone era, the castle was a strange and enchanting place but is now showing signs of age and neglect. Broken windows let the weather in, and the rooms aren’t all what they once were. The house that once felt so comfortable to its inhabitants is now cold and uninviting. The object-oriented paradigm, too, is showing some signs of age, especially the earlier object-oriented implementations. The Java language, with its dated implementations of static typing and concurrency, needs a face-lift. In this section, we’re going to talk primarily about Scala in the context of that house on the hill, the object-oriented programming paradigm.

Scala runs on the Java virtual machine (JVM). I’m not going to offer an exhaustive overview of the Java language; that information is freely available elsewhere. You’ll see some Java ideas creeping through to Scala, but I’ll try to minimize their impact so you won’t have to learn two languages at once. For now, install Scala. I’m using version 2.7.7.final for this book.

Scala Types

When you have Scala working, fire up the console with the command scala. If all is well, you won’t get any error messages, and you will see a scala> prompt. You can then type a little code.

So, integers are objects. In Java, I’ve pulled out my fair share of hair converting between Int (primitives) and Integer (objects). In fact, everything is an object in Scala, with some small exceptions. That’s a significant departure from most statically typed object oriented languages. Let’s see how Scala handles strings:

So a string, too, is a first-class object, with a little syntactic sugar mixed in. Let’s try to force a type collision:

Hm...that’s not quite what we were looking for. Scala is coercing those integers into strings. Let’s try a little harder to force a mismatch:

Ah. That’s the ticket. Scala is actually strongly typed. Scala will use type inference, so most of the time, it will understand the types of variables through syntactical clues, but unlike Ruby, Scala can do that type checking at compile time. Scala’s console actually compiles lines of code and runs each one piecemeal.

On a side note, I know you’re getting back Java strings. Most Scala articles and books go into this topic in more detail, but we can’t do so and still dive into the programming constructs that I think will be most interesting to you. I’ll point you to a few books that will go into the Java integration in detail. For now, I’m going to tell you that in many places, Scala has a strategy for managing types across two languages. Part of that is using simple Java types where they make sense, like java.lang.String. Please trust me, and accept these oversimplifications.

Expressions and Conditions

Now we’re going to move through some basic syntax quickly and strictly by example. Here are a few Scala true/false expressions:

There’s nothing too interesting going on there. This is the C-style syntax that you’re familiar with from several of the languages we’ve talked about so far. Let’s use an expression in an if statement:

We assign a couple of variables and compare them in an if/else statement. Take a closer look at the variable assignment. First, notice that you didn’t specify a type. Unlike Ruby, Scala binds types at compile time. But unlike Java, Scala can infer the type, so you don’t have to type val a : Int = 1, though you can if you want.

Next, notice that these Scala variable declarations start with the val keyword. You can also use the var keyword. val is immutable; var is not. We’ll talk more about this later.

In Ruby, 0 evaluated to true. In C, 0 was false. In both languages, nil evaluated to false. Let’s see how Scala handles them:

So, a Nil is an empty list, and you can’t even test Nil or 0. This behavior is consistent with Scala’s strong, static typing philosophy. Nils and numbers are not booleans, so don’t treat them like booleans. With simple expressions and the most basic decision construct behind us, let’s move on to loops.

Loops

As the next couple of programs get more complex, we’re going to run them as scripts. Like Ruby and Io, you’ll run them with scala path/to/program.scala.

You’ll see a number of ways to iterate over result sets in day 2 when we attack code blocks. For now, we’ll focus on the imperative programming style of loops. You’ll see that these look a lot like Java-style loop structures.

First is the basic while loop:

We define a function. As a side note, Java developers will notice that you don’t have to specify public. In Scala, public is the default visibility, meaning this function will be visible to all.

Within the method, we declare a simple while loop that counts to three. i changes, so we declare it with var. Then, you see a Java-style declaration of a while statement. As you can see, the code inside braces executes unless the condition is false. You can run the code like this:

The for loop works a lot like Java’s and C’s but with a slightly different syntax:

The argument is a variable, followed by the <- operator, followed by a range for the loop in the form of initialValue until endingValue. In this case, we’re iterating over the incoming command-line arguments:

As with Ruby, you can also use loops to iterate over a collection. For now, we’ll start with foreach, which is reminiscent of Ruby’s each:

args is a list with the inbound command-line arguments. Scala passes each element into this block, one by one. In our case, arg is one argument from the inbound args list. In Ruby, the same code would be args.each {|arg| println(arg) }. The syntax for specifying each argument is slightly different, but the idea is the same. Here’s the code in action:

Later, you’ll find yourself using this method of iteration much more often than the other imperative loops. But since we’re concentrating on the house on the hill, we’ll delay that part of the conversation for a little while.

Ranges and Tuples

Like Ruby, Scala supports first-class ranges. Start the console, and enter these code snippets:

That all makes sense. It works like Ruby’s range. You can also specify increments:

The equivalent of Ruby’s range, 1..10, is 1 to 10, and the equivalent of Ruby’s range, 1...10, is 1 until 10. to is inclusive:

You can also specify direction with this:

But the direction is not inferred:

1 is the default step, regardless of the endpoints that you express for your range. You are not limited to integers:

Scala will do some implicit type conversions for you. In fact, when you specified a for statement, you were actually specifying a range.

Like Prolog, Scala offers tuples. A tuple is a fixed-length set of objects. You’ll find this pattern in many other functional languages as well. The objects in a tuple can all have different types. In purely functional languages, programmers often express objects and their attributes with tuples. Try this example:

Scala uses tuples rather than lists to do multivalue assignments:

Since tuples have a fixed length, Scala can do static type checking based on each of the tuple values:

With these foundations out of the way, let’s put it all together. We’ll create some object-oriented class definitions.

Classes in Scala

The simplest classes, those with attributes but no methods or constructors, are simple, one-line definitions in Scala:

You don’t have to specify any body to specify a simple value class. The Person class will be public and have firstName and lastName attributes. And you can use that class in the console:

But you’re looking for a little more. Object-oriented classes mix data and behavior. Let’s build a full object-oriented class in Scala. We’ll call this class Compass. The compass orientation will start with north. We’ll tell the compass to turn 90 degrees left or right and update the direction accordingly. Here’s what the Scala code looks like, in its entirety:

The syntax is relatively straightforward, with a couple of notable peculiarities. The constructor is responsible for defining instance variables (at least, those you don’t pass into the constructor) and methods. Unlike Ruby, all method definitions have parameter types and names. And the initial block of code isn’t in any method definition at all. Let’s take it apart:

The whole block of code following the class definition is actually the constructor. Our constructor has a List of directions and a bearing, which is simply an index for the directions. Later, turning will manipulate the bearing. Next, there are a couple of convenience methods to show the user of the class the current direction, in English:

The constructor continues with method definitions. The direction method just returns the element of directions at the index of bearing. Scala conveniently allows an alternate syntax for one-line methods, omitting the braces around the method body.

The inform method prints a friendly message whenever the user turns. It takes a simple parameter, the direction of the turn. This method doesn’t return a value. Let’s look at the methods to handle turns.

The turns method changes the bearing based on the direction of the turn. The % operator is modular division. (This operator does a division operation, discarding the quotient and returning only the remainder.) The result is that right turns add one to the bearing and left turns subtract one, wrapping the result accordingly.

Auxiliary Constructors

You’ve seen how the basic constructor works. It’s a code block that initializes classes and methods. You can have alternate constructors as well. Consider this Person class, with two constructors:

The class has a constructor with one parameter, firstName, and a method called talk. Notice the this method. That’s the second constructor. It takes two parameters, firstName and lastName. Initially, the method invokes this with the primary constructor, with only the firstName parameter.

The code after the class definition instantiates a person in two ways, first with the primary constructor, then next with the auxiliary constructor:

That’s all there is to it. Auxiliary constructors are important because they allow for a broad array of usage patterns. Let’s look at how to create class methods.

Extending Classes

So far, the classes have been pretty vanilla. We created a couple of basic classes with nothing more than attributes and methods. In this section, we’ll look at some of the ways that classes can interact.

Companion Objects and Class Methods

In Java and Ruby, you create both class methods and instance methods within the same body. In Java, class methods have the static keyword. Ruby uses def self.class_method. Scala uses neither of these strategies. Instead, you will declare instance methods in the class definitions. When there’s something that can have only one instance, you’ll define it with the object keyword instead of the class keyword. Here’s an example:

The TrueRing definition works exactly like any class definition, but it creates a singleton object. In Scala, you can have both an object definition and a class definition with the same name. Using this scenario, you can create class methods within the singleton object declaration and instance methods within the class declaration. In our example, the method rule is a class method. This strategy is called companion objects.

Inheritance

Inheritance in Scala is pretty straightforward, but the syntax must be exact. Here’s an example of extending a Person class with Employee. Notice that the Employee has an additional employee number in the id field. Here’s the code:

In this example, we’re extending the Person base class with Employee. We’re adding a new instance variable called number in Employee, and we’re also overriding the talk message to add some new behavior. Most of the tricky syntax is around the class constructor definition. Notice that you must specify the complete parameter list for Person, though you can omit the types.

The override keyword, both in the constructor and for any methods you want to extend from the base class, is mandatory. This keyword will keep you from inadvertently introducing new methods with misspellings. All in all, there are no major surprises here, but at times, I do feel a bit like Edward trying to pet a fragile baby bunny. Moving on....

Traits

Every object-oriented language must solve the problem that one object can have several different roles. An object can be a persistent, serializable shrubbery. You don’t want your shrubbery to have to know how to push binary data into MySQL. C++ uses multiple inheritance, Java uses interfaces, Ruby uses mixins, and Scala uses traits. A Scala trait is like a Ruby mixin, implemented with modules. Or, if you prefer, a trait is like a Java interface plus an implementation. Look at a trait as a partial-class implementation. Ideally, it should implement one critical concern. Here’s an example that adds the trait Nice to Person:

The first element you see is Person. It is a simple class with a single attribute called name. The second element is the trait called Nice. That is the mixin. It has a single method called greet. The final element, a class called Character, mixes in the Nice trait. Clients can now use the greet method on any instance of Character. The output is what you would expect:

There’s nothing too complicated here. We can take our trait called Nice with a method called greet and mix it into any Scala class to introduce the greet behavior.

What We Learned in Day 1

We covered a tremendous amount of territory in day 1 because we have to fully develop two different programming paradigms in one language. Day 1 showed that Scala embraces object-oriented concepts, running in the JVM side-by-side with existing Java libraries. Scala’s syntax is similar to that of Java and is also strongly and statically typed. But Martin Odersky wrote Scala to bridge two paradigms: object-oriented programming and functional programming. These functional programming concepts that we’ll introduce in day 2 will make it easier to design concurrent applications.

Scala’s static typing is also inferred. Users do not always need to declare types for all variables in all situations because Scala can often infer those types from syntactical clues. The compiler can also coerce types, such as integers to strings, allowing implicit type conversions when they make sense.

Scala’s expressions work much like they do in other languages, but they are a little more strict. Most conditionals must take a boolean type, and 0 or Nil will not work at all; they can substitute for neither true nor false. But there’s nothing dramatically different about Scala’s looping or control structures. Scala does support some more advanced types, like tuples (fixed-length lists with heterogeneous types) and ranges (a fixed, all-inclusive ordered sequence of numbers).

Scala classes work much like they do in Java, but they don’t support class methods. Instead, Scala uses a concept called companion objects to mix class and instance methods on the same class. Where Ruby uses mixins and Java uses interfaces, Scala uses a structure like a mixin called a Trait.

In day 2, we’ll take a full pass through Scala’s functional features. We’ll cover code blocks, collections, immutable variables, and some advanced built-in methods like foldLeft.

Day 1 Self-Study

The first day of Scala covered a lot of ground, but it should be mostly familiar territory. These object-oriented concepts should be familiar to you. These exercises are a little advanced compared to the earlier exercises in the book, but you can handle it.

Find:

• The Scala API

• A comparison of Java and Scala

• A discussion of val versus var

Do:

• Write a game that will take a tic-tac-toe board with X, O, and blank characters and detect the winner or whether there is a tie or no winner yet. Use classes where appropriate.

• Bonus problem: Let two players play tic-tac-toe.