Chapter 1
Language Features

WHAT'S IN THIS CHAPTER?

• Outlining various control structures in Scala
• Using various tools in the standard library
• Mastering inheritance and composition in Scala

Scala borrows many of its syntax and control structures from various other languages. Methods are declared in Algol/C style with the addition of features such as optional braces, and semicolons to reduce code boilerplate.

Scala syntax also has features such as expressions for statements, local type inference, suffix/infix notation, and implicit return statements, which make typical idiomatic Scala code look like dynamic languages such as Lisp/Python/Ruby, but with the added benefit of strong static typing.

The expressive nature of Scala's syntax is useful to create custom DSL's, with the most notable example being Scala's own XML library. Scala also features several forms of inheritance (traits, classes, objects), which can be combined in various ways to structure composition in your code in a more natural and elegant way. This combined with a strong support for functional programming, syntactic sugar (for comprehension), and type inference makes it possible to create very terse domain specific code that is also type safe.

This chapter provides a broad overview of the various parts of Scala's design and syntax, as well as the features that are expected in modern generic programming languages (control of scoping, string interpolation, encapsulation, and modules).

STATIC TYPES AND TYPE INFERENCE

Scala is first and foremost a statically typed language, which is similar to other statically typed ­languages you can annotate types for:

• Variable declarations
• Method/function arguments
• Method/function return values
• Various types of data structures

Below is a code sample to demonstrate these types of annotations:

A significant reason why Scala requires mandatory type signatures is that it's very difficult to provide a practical implementation of global type inference in a statically typed language that supports subtyping. Thankfully, while Scala mandates that you provide type signatures for method parameters and type definitions, for variable declarations inside function/method bodies it features local type inference. This drastically reduces the amount of boilerplate code when it comes to function/method bodies. Here is an example of local type inference in action.

As you can see for variable declarations, you don't need to specify their respective types. To ­manually specify the types, do the following:

One bonus of specifying types for function arguments is that they also act as a form of ­documentation, which is particularly helpful. Return types of functions are also optional; however, it is encouraged to annotate them for documentation/clarity reasons. Due to Scala's generic code functionality, it is possible to have expressions that return different values in ­unexpected scenarios. One good example is Int's versus Double:

Since f and f_v2 don't have their return types annotated, we aren't aware of what types they can return (let's assume you don't know what the actual values of f and f_v2 are). This means that the f == 342342 expression returns something else compared to f_v2 == 342342. If, however, you know the return types of f and f_v2, you can do the following:

As a user, you know that the return type of f is a Double, so don't compare it with an Int when asking for equality ( since it's a Float by extension you should provide custom equality with a delta).

Manual type signatures can also be used to force the type of a declaration. This is similar to the typecast feature in languages like Java or C; however, it's more powerful due to type conversions available in Scala. A simple example in Scala is to assign a Long type to an integer literal.

By default, if you use a number literal in Scala it defaults to an Int. Note that it is also possible to use the number based suffix like so:

Arguably, the type annotation is more idiomatic, especially for custom types that may not have literal operators.

Implicit Parameters, Conversions, and Their Resolution

Scala has an incredibly powerful feature called implicits. When you ask for a value implicitly, such as a method parameter, or the implicit keyword you are telling the Scala compiler to look for a value that has the same type in scope. This is unlike the explicit value, where you need a type to specify when it's called/used. A practical use case for implicits is providing an API key for a REST web service. The API key is typically only provided once, so an implicit is a good use case in this instance, since you only need to define and import it once.

Since implicits are found by their type you need to create a new type, in this case ApiKey. Now let's define a method that makes a HTTP call.

In order to call this function you must make sure that an implicit ApiKey is visible in the scope. Let's first make an instance of ApiKey and place it in an object.

Whenever you call getUser, ApiKey needs to be visible, and the code should look something like this:

It's also possible to supply an implicit argument explicitly.

Implicits can be used to make automatic conversions between types; however, such usage is considered advanced and should be done sparingly, because it's easy to abuse code that uses these features. A prominent use of implicit conversions is in DSLs. For example, if you have a trivial DSL that attempts to represent SQL queries, you might have something like this:

In this case, _.firstName may be a different type from a String (in this example, let's say it has type Column[String]). And it can only work on types of Column[String]:

To compare two instances of Column[String] (to see if they are equal) you want an implicit con­version of String to Column[String], so that you don't have to write:

To do this you need to define the following:

In this case, when you import your stringToColumnStringConverter, it will automatically convert any instances of String to Column[String] if it's required to do so. Since the is method only works on Column[String], the compiler will try to see if there is an implicit conversion available for the String "BoB," so it can satisfy the method signature for is.

Implicit classes are a type safe solution that Scala provides for monkey patching (extending an existing class, or in Scala's case, a type without having to modify the existing source of the type). Let's try this by adding a replaceSpaceWithUnderScore method to a String.

Like the previous example, you need to import this class to make it available:

Case Class, Tuples, and Case Object

Scala has a feature called case class, which is a fundamental structure to represent an immutable data. A case class contains various helper methods, which provide automatic...