Odersky M. Programming in Scala
Подождите немного. Документ загружается.
Section 11.2 Chapter 11 · Scala’s Hierarchy 241
Scala classes are different from Java classes in that they also inherit from
a special marker trait called ScalaObject. The idea is that the ScalaObject
contains methods that the Scala compiler defines and implements in order to
make execution of Scala programs more efficient. Right now, Scala object
contains a single method, named $tag, which is used internally to speed up
pattern matching.
11.2 How primitives are implemented
How is all this implemented? In fact, Scala stores integers in the same way
as Java: as 32-bit words. This is important for efficiency on the JVM and
also for interoperability with Java libraries. Standard operations like addition
or multiplication are implemented as primitive operations. However, Scala
uses the “backup” class java.lang.Integer whenever an integer needs to
be seen as a (Java) object. This happens for instance when invoking the
toString method on an integer number or when assigning an integer to a
variable of type Any. Integers of type Int are converted transparently to
“boxed integers” of type java.lang.Integer whenever necessary.
All this sounds a lot like auto-boxing in Java 5 and it is indeed quite
similar. There’s one crucial difference, though, in that boxing in Scala is
much less visible than boxing in Java. Try the following in Java:
// This is Java
boolean isEqual(int x, int y) {
return x == y;
}
System.out.println(isEqual(421, 421));
You will surely get true. Now, change the argument types of isEqual to
java.lang.Integer (or Object, the result will be the same):
// This is Java
boolean isEqual(Integer x, Integer y) {
return x == y;
}
System.out.println(isEqual(421, 421));
You will find that you get false! What happens is that the number 421
gets boxed twice, so that the arguments for x and y are two different objects.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 11.2 Chapter 11 · Scala’s Hierarchy 242
Because == means reference equality on reference types, and Integer is a
reference type, the result is false. This is one aspect where it shows that
Java is not a pure object-oriented language. There is a difference between
primitive types and reference types that can be clearly observed.
Now try the same experiment in Scala:
scala> def isEqual(x: Int, y: Int) = x == y
isEqual: (Int,Int)Boolean
scala> isEqual(421, 421)
res10: Boolean = true
scala> def isEqual(x: Any, y: Any) = x == y
isEqual: (Any,Any)Boolean
scala> isEqual(421, 421)
res11: Boolean = true
In fact, the equality operation == in Scala is designed to be transparent with
respect to the type’s representation. For value types, it is the natural (numeric
or boolean) equality. For reference types, == is treated as an alias of the
equals method inherited from Object. That method is originally defined
as reference equality, but is overridden by many subclasses to implement
their natural notion of equality. This also means that in Scala you never fall
into Java’s well-known trap concerning string comparisons. In Scala, string
comparison works as it should:
scala> val x = "abcd".substring(2)
x: java.lang.String = cd
scala> val y = "abcd".substring(2)
y: java.lang.String = cd
scala> x == y
res12: Boolean = true
In Java, the result of comparing x with y would be false. The programmer
should have used equals in this case, but it is easy to forget.
However, there are situations where you need reference equality instead
of user-defined equality. For example, in some situations where efficiency is
paramount, you would like to hash cons with some classes and compare their
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 11.3 Chapter 11 · Scala’s Hierarchy 243
instances with reference equality.
2
For these cases, class AnyRef defines
an additional eq method, which cannot be overridden and is implemented
as reference equality (i.e., it behaves like == in Java for reference types).
There’s also the negation of eq, which is called ne. For example:
scala> val x = new String("abc")
x: java.lang.String = abc
scala> val y = new String("abc")
y: java.lang.String = abc
scala> x == y
res13: Boolean = true
scala> x eq y
res14: Boolean = false
scala> x ne y
res15: Boolean = true
Equality in Scala is discussed further in Chapter 28.
11.3 Bottom types
At the bottom of the type hierarchy in Figure 11.1 you see the two classes
scala.Null and scala.Nothing. These are special types that handle some
“corner cases” of Scala’s object-oriented type system in a uniform way.
Class Null is the type of the null reference; it is a subclass of every
reference class (i.e., every class that itself inherits from AnyRef). Null is not
compatible with value types. You cannot, for example, assign a null value
to an integer variable:
scala> val i: Int = null
<console>:4: error: type mismatch;
found : Null(null)
required: Int
2
You hash cons instances of a class by caching all instances you have created in a weak
collection. Then, any time you want a new instance of the class, you first check the cache.
If the cache already has an element equal to the one you are about to create, you can reuse
the existing instance. As a result of this arrangement, any two instances that are equal with
equals() are also equal with reference equality.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 11.4 Chapter 11 · Scala’s Hierarchy 244
Type Nothing is at the very bottom of Scala’s class hierarchy; it is a sub-
type of every other type. However, there exist no values of this type whatso-
ever. Why does it make sense to have a type without values? As discussed in
Section 7.4, one use of Nothing is that it signals abnormal termination. For
instance there’s the error method in the Predef object of Scala’s standard
library, which is defined like this:
def error(message: String): Nothing =
throw new RuntimeException(message)
The return type of error is Nothing, which tells users that the method will
not return normally (it throws an exception instead). Because Nothing is a
subtype of every other type, you can use methods like error in very flexible
ways. For instance:
def divide(x: Int, y: Int): Int =
if (y != 0) x / y
else error("can't divide by zero")
The “then” branch of the conditional, x / y, has type Int, whereas the else
branch, the call to error, has type Nothing. Because Nothing is a subtype
of Int, the type of the whole conditional is Int, as required.
11.4 Conclusion
In this chapter we showed you the classes at the top and bottom of Scala’s
class hierarchy. Now that you’ve gotten a good foundation on class inher-
itance in Scala, you’re ready to understand mixin composition. In the next
chapter, you’ll learn about traits.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Chapter 12
Traits
Traits are a fundamental unit of code reuse in Scala. A trait encapsulates
method and field definitions, which can then be reused by mixing them into
classes. Unlike class inheritance, in which each class must inherit from just
one superclass, a class can mix in any number of traits. This chapter shows
you how traits work and shows two of the most common ways they are use-
ful: widening thin interfaces to rich ones, and defining stackable modifica-
tions. It also shows how to use the Ordered trait and compares traits to the
multiple inheritance of other languages.
12.1 How traits work
A trait definition looks just like a class definition except that it uses the key-
word trait. An example is shown in Listing 12.1:
trait Philosophical {
def philosophize() {
println("I consume memory, therefore I am!")
}
}
Listing 12.1 · The definition of trait Philosophical.
This trait is named Philosophical. It does not declare a superclass, so
like a class, it has the default superclass of AnyRef. It defines one method,
named philosophize, which is concrete. It’s a simple trait, just enough to
show how traits work.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 12.1 Chapter 12 · Traits 246
Once a trait is defined, it can be mixed in to a class using either the
extends or with keywords. Scala programmers “mix in” traits rather than
inherit from them, because mixing in a trait has important differences from
the multiple inheritance found in many other languages. This issue is dis-
cussed in Section 12.6. For example, Listing 12.2 shows a class that mixes
in the Philosophical trait using extends:
class Frog extends Philosophical {
override def toString = "green"
}
Listing 12.2 · Mixing in a trait using extends.
You can use the extends keyword to mix in a trait; in that case you
implicitly inherit the trait’s superclass. For instance, in Listing 12.2, class
Frog subclasses AnyRef (the superclass of Philosophical) and mixes in
Philosophical. Methods inherited from a trait can be used just like meth-
ods inherited from a superclass. Here’s an example:
scala> val frog = new Frog
frog: Frog = green
scala> frog.philosophize()
I consume memory, therefore I am!
A trait also defines a type. Here’s an example in which Philosophical is
used as a type:
scala> val phil: Philosophical = frog
phil: Philosophical = green
scala> phil.philosophize()
I consume memory, therefore I am!
The type of phil is Philosophical, a trait. Thus, variable phil could have
been initialized with any object whose class mixes in Philosophical.
If you wish to mix a trait into a class that explicitly extends a superclass,
you use extends to indicate the superclass and with to mix in the trait.
Listing 12.3 shows an example. If you want to mix in multiple traits, you
add more with clauses. For example, given a trait HasLegs, you could mix
both Philsophical and HasLegs into Frog as shown in Listing 12.4.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 12.1 Chapter 12 · Traits 247
class Animal
class Frog extends Animal with Philosophical {
override def toString = "green"
}
Listing 12.3 · Mixing in a trait using with.
class Animal
trait HasLegs
class Frog extends Animal with Philosophical with HasLegs {
override def toString = "green"
}
Listing 12.4 · Mixing in multiple traits.
In the examples you’ve seen so far, class Frog has inherited an imple-
mentation of philosophize from trait Philosophical. Alternatively, Frog
could override philosophize. The syntax looks the same as overriding a
method declared in a superclass. Here’s an example:
class Animal
class Frog extends Animal with Philosophical {
override def toString = "green"
override def philosophize() {
println("It ain't easy being "+ toString +"!")
}
}
Because this new definition of Frog still mixes in trait Philosophize, you
can still use it from a variable of that type. But because Frog overrides
Philosophical’s implementation of philosophize, you’ll get a new be-
havior when you call it:
scala> val phrog: Philosophical = new Frog
phrog: Philosophical = green
scala> phrog.philosophize()
It ain't easy being green!
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 12.2 Chapter 12 · Traits 248
At this point you might philosophize that traits are like Java interfaces
with concrete methods, but they can actually do much more. Traits can, for
example, declare fields and maintain state. In fact, you can do anything in
a trait definition that you can do in a class definition, and the syntax looks
exactly the same, with only two exceptions. First, a trait cannot have any
“class” parameters, i.e., parameters passed to the primary constructor of a
class. In other words, although you could define a class like this:
class Point(x: Int, y: Int)
The following attempt to define a trait would not compile:
trait NoPoint(x: Int, y: Int) // Does not compile
You’ll find out in Section 20.5 how to work around this restriction.
The other difference between classes and traits is that whereas in classes,
super calls are statically bound, in traits, they are dynamically bound. If
you write “super.toString” in a class, you know exactly which method
implementation will be invoked. When you write the same thing in a trait,
however, the method implementation to invoke for the super call is unde-
fined when you define the trait. Rather, the implementation to invoke will
be determined anew each time the trait is mixed into a concrete class. This
curious behavior of super is key to allowing traits to work as stackable mod-
ifications, which will be described in Section 12.5. The rules for resolving
super calls will be given in Section 12.6.
12.2 Thin versus rich interfaces
One major use of traits is to automatically add methods to a class in terms
of methods the class already has. That is, traits can enrich a thin interface,
making it into a rich interface.
Thin versus rich interfaces represents a commonly faced trade-off in
object-oriented design. The trade-off is between the implementers and the
clients of an interface. A rich interface has many methods, which make it
convenient for the caller. Clients can pick a method that exactly matches
the functionality they need. A thin interface, on the other hand, has fewer
methods, and thus is easier on the implementers. Clients calling into a thin
interface, however, have to write more code. Given the smaller selection of
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 12.3 Chapter 12 · Traits 249
methods to call, they may have to choose a less than perfect match for their
needs and write extra code to use it.
Java’s interfaces are more often thin than rich. For example, interface
CharSequence, which was introduced in Java 1.4, is a thin interface com-
mon to all string-like classes that hold a sequence of characters. Here’s its
definition when seen as a Scala trait:
trait CharSequence {
def charAt(index: Int): Char
def length: Int
def subSequence(start: Int, end: Int): CharSequence
def toString(): String
}
Although most of the dozens of methods in class String would apply to
any CharSequence, Java’s CharSequence interface declares only four meth-
ods. Had CharSequence instead included the full String interface, it would
have placed a large burden on implementers of CharSequence. Every pro-
grammer that implemented CharSequence in Java would have had to define
dozens more methods. Because Scala traits can contain concrete methods,
they make rich interfaces far more convenient.
Adding a concrete method to a trait tilts the thin-rich trade-off heavily
towards rich interfaces. Unlike in Java, adding a concrete method to a Scala
trait is a one-time effort. You only need to implement the method once, in
the trait itself, instead of needing to reimplement it for every class that mixes
in the trait. Thus, rich interfaces are less work to provide in Scala than in a
language without traits.
To enrich an interface using traits, simply define a trait with a small num-
ber of abstract methods—the thin part of the trait’s interface—and a poten-
tially large number of concrete methods, all implemented in terms of the
abstract methods. Then you can mix the enrichment trait into a class, imple-
ment the thin portion of the interface, and end up with a class that has all of
the rich interface available.
12.3 Example: Rectangular objects
Graphics libraries often have many different classes that represent something
rectangular. Some examples are windows, bitmap images, and regions se-
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 12.3 Chapter 12 · Traits 250
lected with a mouse. To make these rectangular objects convenient to use,
it is nice if the library provides geometric queries such as width, height,
left, right, topLeft, and so on. However, many such methods exist that
would be nice to have, so it can be a large burden on library writers to pro-
vide all of them for all rectangular objects in a Java library. If such a library
were written in Scala, by contrast, the library writer could use traits to easily
supply all of these convenience methods on all the classes they’d like.
To see how, first imagine what the code would look like without traits.
There would be some basic geometric classes like Point and Rectangle:
class Point(val x: Int, val y: Int)
class Rectangle(val topLeft: Point, val bottomRight: Point) {
def left = topLeft.x
def right = bottomRight.x
def width = right - left
// and many more geometric methods...
}
This Rectangle class takes two points in its primary constructor: the co-
ordinates of the top-left and bottom-right corners. It then implements many
convenience methods such as left, right, and width by performing simple
calculations on these two points.
Another class a graphics library might have is a 2-D graphical widget:
abstract class Component {
def topLeft: Point
def bottomRight: Point
def left = topLeft.x
def right = bottomRight.x
def width = right - left
// and many more geometric methods...
}
Notice that the definitions of left, right, and width are exactly the same
in the two classes. They will also be the same, aside from minor variations,
in any other classes for rectangular objects.
This repetition can be eliminated with an enrichment trait. The trait will
have two abstract methods: one that returns the top-left coordinate of the ob-
ject, and another that returns the bottom-right coordinate. It can then supply
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index