Pollak D. Beginning Scala
Подождите немного. Документ загружается.
CHAPTER 6 ■ ACTORS AND CONCURRENCY
167
Next, we define the messages for a generic listener:
case class Add(who: Actor)
case class Remove(who: Actor)
We define the ListenerMgt trait that extends Buildable, has private state and imple-
ments the
updateListeners method, and requires the updateMessage method to be
implemented:
trait ListenerMgt extends Buildable {
private var listeners: List[Actor] = Nil
We implement the handler method by composing the superclass’s handler with this
class’s message handler:
override def handler = super.handler orElse {
case Add(who) =>
listeners = who :: listeners
who ! updateMessage
case Remove(who) => listeners -= who
}
We update all the listeners:
protected def updateListeners() {
val m = updateMessage
listeners.foreach(a => a ! m)
}
Any class that mixes this trait in must implement the updateMessage method:
protected def updateMessage: Any
}
We’ve implemented ListenerMgt. Now, let’s implement a trait, GetMgt, which will
respond to the
GetInfo message with the result of the updateMessage call:
case object GetInfo
trait GetMgt extends Buildable {
override def handler = super.handler orElse {
case GetInfo => reply(updateMessage)
}
protected def updateMessage: Any
}
19897ch06.fm Page 167 Monday, April 20, 2009 11:10 AM
168
CHAPTER 6
■ ACTORS AND CONCURRENCY
Finally, let’s create a Chat server that composes the ListenerMgt and GetMgt traits into an
Actor and then adds
Chat-specific functionality:
case class Messages(msgs: List[String])
object Chat extends Actor with ListenerMgt with GetMgt {
private var msgs: List[String] = Nil
def act = loop {
react(handler orElse {
case s: String => msgs = s :: msgs
updateListeners()
})
}
protected def updateMessage = Messages(msgs)
this.start
}
The composition of Actor with ListenerMgt with GetMgt builds a class that has all of
these traits combined. During the composition,
ListenerMgt becomes the superclass of
GetMgt, so GetMgt’s super.handler call will invoke ListenerMgt’s handler method. This allows
us to chain the calls to
handler and compose the PartialFunction that we pass to react. We
add in the
Chat-specific PartialFunction, and we’ve got a complete Chat server. Let’s write
some code to check it out.
class Listen extends Actor {
def act = loop {
react {
case Messages(m) => println("Got "+m)
}
}
this.start
}
Let’s run the code and see what happens:
scala> val listen = new Listen
listen: Listen = Listen@10cc9b4
19897ch06.fm Page 168 Monday, April 20, 2009 11:10 AM
CHAPTER 6 ■ ACTORS AND CONCURRENCY
169
scala> Chat ! Add(listen)
Got List()
scala> Chat ! "Hello"
Got List(Hello)
scala> Chat ! "Dude"
Got List(Dude, Hello)
scala> Chat !? GetInfo
res3: Any = Messages(List(Dude, Hello))
This is a simple example of composing an Actor out of generic pieces. The generic
pieces can be combined into a single Actor class that provides specific business logic as
well as the more generic functionality of listeners and so on.
Summary
In this chapter, we explored Scala Actors. Actors provide an alternative model for concur-
rency that feels to me a whole lot like coarse-grained OOP. Philipp Haller is a member of
Martin Odersky’s group and is primarily responsible for Scala’s Actor design and imple-
mentation. Philipp has written a number of papers on Actors that provide a lot of valuable
insight into his design choices as well as Actor implementation.
11
There is plenty more
11. Philipp Haller and Martin Odersky, “Event Based Programming without Inversion of Control,” http://
lampwww.epfl.ch/~odersky/papers/jmlc06.pdf and Philipp Haller and Martin Odersky, “Actors that
Unify Threads and Events,” http://lamp.epfl.ch/~phaller/doc/haller07coord.pdf.
19897ch06.fm Page 169 Monday, April 20, 2009 11:10 AM
170
CHAPTER 6
■ ACTORS AND CONCURRENCY
depth in terms of the use and features of Scala Actors than I covered in this chapter. If
Actors seem like a good tool in your software tool chest, please dig deeper, because there
is a lot more good stuff to Actors.
Up to now, we’ve been focusing on what I call the library-consumer coding. We’ve
been writing code that consumes the libraries provided by Scala. Scala has a more complex
side based on its type system and traits. In the next chapter, we’re going to go where there
be dragons and explore the kind of gnarly stuff that library authors use to make sure the
programs that library consumers write are type-safe and concise. Please put on your
thinking cap and your hip waders, and let’s do some hard-core Scala.
19897ch06.fm Page 170 Monday, April 20, 2009 11:10 AM
171
■ ■ ■
CHAPTER 7
Traits and Types and Gnarly
Stuff for Architects
So far, we’ve explored Scala from what I consider the “library-consumer” perspective.
For the most part, when I’m consuming libraries, I don’t worry about complex types,
composing many traits into a class, or some of the other powerful features of Scala. “Why?”
you may ask. Well, I’m worried about the transformation of input to output, happily
mapping
Lists, and filtering Seqs. When I’m coding in this mode, I’m not reasoning about
my types, but I’m confident that Scala will make sure I don’t do anything horribly wrong
and that as long as my logic is sound, my code will work. When I’m in this mode, I’m writing
code the same way I write Ruby code: I’m looking to get something to work and get some
work done.
There are other times when I am designing libraries for other folks to consume. I do this
for the Lift Web Framework and for my consulting projects. In this case, I spend a lot more
time making sure that the constraints are in place for writing correct code. It takes a lot of
time for me to reason about the constraints and then to reduce them to code. When I’m in
this mode, I write fewer lines of code, but they are more descriptive. I call this “library
producer” mode.
You may be asking, “Why not always code in this mode?” It’s because most problems
are not solved by coding in this mode. Most of my coding tasks are some variant of, “Here’s
some user input, and it should be tested this way, and if it’s valid then it should update
state and send the following events.” Reasoning about types is hard and slow work for me.
Choosing implicit conversions and designing domain-specific languages (DSLs) takes
time, thought, and deliberation. Using types, especially when type inferencing makes
them invisible, is simple and doesn’t take a lot of thought away from the task at hand.
Well-defined types and type interactions will stay out of the library consumer’s way but
guard against program errors. Similarly, a well-defined DSL will make expressing program
logic faster and easier to maintain.
19897ch07.fm Page 171 Monday, April 20, 2009 4:36 PM
172
CHAPTER 7
■ TRAITS AND TYPES AND GNARLY STUFF FOR ARCHITECTS
Scala is unique among the languages I’ve used in that it gives a different set of tools and
powers to different team members. Scala’s traits, type system, flexible syntax, and implicit
conversions give amazingly powerful tools to architects and library designers to build
libraries that are simultaneously easy and safe to use. Safety means that tests can focus on
the logic of code, not calling conventions. We’ve seen some examples of the safety of
using
Option instead of null testing. Being able to reason about the safety by making sure
that things have the correct types is very powerful. It also means that the library consumers
can focus on their business logic without worrying about declaring lots of fancy types or
other distractions. Library consumers don’t have to program defensively, because they
can trust the correctness of parameters and of return values.
This chapter is a deep dive into the language features that make Scala different from
Java. These are tools that I use when I design code bases for other people to consume.
These tools let me write code that I can reason is correct, so when I go to write application
code, I can be sure that my code is correct if my logic is correct. I can write logic-oriented
tests rather than tests that try to fool my code and make sure that I’m guarding against
nulls or other parameter and type-related problems.
1
Show Me Some Bad Java Code
So, I’ve talked about Java code not being as type-safe as Scala code. You’re probably
thinking, “But Java is a statically typed language, doesn’t it give me all the safety that Scala
does?” The answer to that is no. Take a look at the following code and spot the problem:
public class Bad {
public static void main(String[] argv) {
Object[] a = argv;
a[0] = new Object();
}
}
This is legal Java code, and here’s what happens when we run the code:
> java Bad Hello
Exception in thread "main" java.lang.ArrayStoreException: java.lang.Object
at Bad.main(Bad.java:4)
1. Among enthusiasts of other statically typed languages with rich type systems (Standard ML, Haskell,
OCaml) the “architect style” is often referred to as “typeful programming,” referring exactly to this
distinction between “going with the type inference flow” and “using the type system deliberately to
encode important invariants.”
19897ch07.fm Page 172 Monday, April 20, 2009 4:36 PM
CHAPTER 7 ■ TRAITS AND TYPES AND GNARLY STUFF FOR ARCHITECTS
173
Java allows us to assign a String[] to Object[]. This is because a String is a subclass of
Object, so if the array was read-only, the assignment would make sense. However, the
array can be modified. The modification that we’ve demonstrated shows one of Java’s
“type-unsafety” features. We’ll discuss why this happened and the very complex topic of
invariant, covariant, and contravariant types later in this chapter.
Let’s start looking at how Scala makes the architect’s job easier and makes the coder’s
job easier.
Library Pimping, Implicit Conversions, and
Vampires
We’ve seen a little bit of stuff so far that looks like magic. The String class seems to have
grown methods:
scala> "Hello".toList
res0: List[Char] = List(H, e, l, l, o)
You may be wondering how a Java class that is final could have additional methods on
it. Well, Scala has a feature called implicit conversion. If you have an instance of a partic-
ular type, and you need another type, and there’s an implicit conversion in scope, Scala
will call the
implicit method to perform the conversion. For example, some date-related
methods take
Long, and some take java.util.Date. It’s useful to have conversions between
the two. We create a method that calculates the number of days based on a
Long containing
a millisecond count:
scala> def millisToDays(in: Long): Int = (in / (1000L * 3600L * 24L)).toInt
We can calculate the number of days by passing a Long to the method:
scala> millisToDays(5949440999L)
res3: Int = 68
However, if we try to pass a Date into the method, we—correctly—get an error:
scala> import java.util.Date
import java.util.Date
scala> millisToDays(new Date)
19897ch07.fm Page 173 Monday, April 20, 2009 4:36 PM
174
CHAPTER 7
■ TRAITS AND TYPES AND GNARLY STUFF FOR ARCHITECTS
<console>:7: error: type mismatch;
found : java.util.Date
required: Long
millisToDays(new Date)
^
But sometimes it’s valuable to convert between one type and another. We are used to
the conversion in some contexts:
Int ➤ Long, Int ➤ Double, and so on. We can define a
method that will automatically be called when we need the conversion:
scala> implicit def dateToLong(d: Date) = d.getTime
dateToLong: (java.util.Date)Long
And this allows us to call millisToDays with a Date instance:
scala> millisToDays(new Date)
res5: Int = 14286
You may think that implicit conversions are dangerous and reduce type safety. In some
cases that’s true. You should be very careful with them, and their use should be an explicit
design choice. However, we see that sometimes implicit conversions (e.g.,
Int ➤ Long) are
very valuable, for example, when we have a method that takes a parameter that must be a
Long:
scala> def m2[T <: Long](in: T): Int = (in / (1000L * 3600L * 24L)).toInt
m2: [T <: Long](T)Int
scala> m2(33)
<console>:8: error: inferred type arguments [Int] do not conform to method m2's
type parameter bounds [T <: Long]
m2(33)
^
19897ch07.fm Page 174 Monday, April 20, 2009 4:36 PM
CHAPTER 7 ■ TRAITS AND TYPES AND GNARLY STUFF FOR ARCHITECTS
175
So having to type the following could get very old:
scala> m2(33.toLong)
res8: Int = 0
This is why implicit conversion is built into the Java compiler and why it’s part of the
standard Scala
Predef.
2
Library Pimping
3
The implicit conversion gets us halfway to adding methods to a final class. The second
half of the journey is that the Scala compiler will look to a possible implicit conversion
from the type you have to a type with the method that you’re invoking. The Scala compiler
will insert code to call the implicit conversion and then call the method on the resulting
instance. For example:
"Hello".toList
gets converted into
Predef.stringWrapper("Hello").toList
The ability to add new methods to existing classes has a lot of value for making code
more readable and expressive. More importantly, implicit conversions make it possible to
define DSLs in Scala.
As a library producer, we can create syntactically pleasing ways of expressing concepts
in a type-safe way. Wouldn’t it be nice to express a time span as
3 days or 15 seconds?
Wouldn’t that make code a lot more readable than
(3L * 24L * 3600L * 1000L)? Wouldn’t
it be great to set a timeout or a trigger with
2.hours.later? Let’s define a library using
implicit conversions. Let’s look at the code in Listing 7-1 and then break it down.
2. The Predef is the stuff that the compiler imports by default. You can see what implicit conversions are
defined in Predef by reading http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_7_3_final/
src/library/scala/Predef.scala?view=markup.
3. Dr. Martin Odersky, ACM Fellow, Full Professor, coined the term in this blog post: http://www.artima.com/
weblogs/viewpost.jsp?thread=179766.
19897ch07.fm Page 175 Monday, April 20, 2009 4:36 PM
176
CHAPTER 7
■ TRAITS AND TYPES AND GNARLY STUFF FOR ARCHITECTS
Listing 7-1. Timespan DSL
import java.util.Date
object TimeHelpers {
case class TimeSpanBuilder(val len: Long) {
def seconds = TimeSpan(TimeHelpers.seconds(len))
def second = seconds
def minutes = TimeSpan(TimeHelpers.minutes(len))
def minute = minutes
def hours = TimeSpan(TimeHelpers.hours(len))
def hour = hours
def days = TimeSpan(TimeHelpers.days(len))
def day = days
def weeks = TimeSpan(TimeHelpers.weeks(len))
def week = weeks
}
def seconds(in: Long): Long = in * 1000L
def minutes(in: Long): Long = seconds(in) * 60L
def hours(in: Long): Long = minutes(in) * 60L
def days(in: Long): Long = hours(in) * 24L
def weeks(in: Long): Long = days(in) * 7L
implicit def longToTimeSpanBuilder(in: Long): TimeSpanBuilder =
TimeSpanBuilder(in)
implicit def intToTimeSpanBuilder(in: Int): TimeSpanBuilder =
TimeSpanBuilder(in)
def millis = System.currentTimeMillis
case class TimeSpan(millis: Long) extends Ordered[TimeSpan] {
def later = new Date(millis + TimeHelpers.millis)
def ago = new Date(TimeHelpers.millis - millis)
def +(in: TimeSpan) = TimeSpan(this.millis + in.millis)
def -(in: TimeSpan) = TimeSpan(this.millis - in.millis)
def compare(other: TimeSpan) = millis compare other.millis
}
19897ch07.fm Page 176 Monday, April 20, 2009 4:36 PM