- •Contents
- •List of Figures
- •List of Tables
- •List of Listings
- •Foreword
- •Foreword to the First Edition
- •Acknowledgments
- •Introduction
- •A Scalable Language
- •A language that grows on you
- •What makes Scala scalable?
- •Why Scala?
- •Conclusion
- •First Steps in Scala
- •Conclusion
- •Next Steps in Scala
- •Conclusion
- •Classes and Objects
- •Semicolon inference
- •Singleton objects
- •A Scala application
- •Conclusion
- •Basic Types and Operations
- •Some basic types
- •Literals
- •Operators are methods
- •Arithmetic operations
- •Relational and logical operations
- •Bitwise operations
- •Object equality
- •Operator precedence and associativity
- •Rich wrappers
- •Conclusion
- •Functional Objects
- •Checking preconditions
- •Self references
- •Auxiliary constructors
- •Method overloading
- •Implicit conversions
- •A word of caution
- •Conclusion
- •Built-in Control Structures
- •If expressions
- •While loops
- •For expressions
- •Match expressions
- •Variable scope
- •Conclusion
- •Functions and Closures
- •Methods
- •Local functions
- •Short forms of function literals
- •Placeholder syntax
- •Partially applied functions
- •Closures
- •Special function call forms
- •Tail recursion
- •Conclusion
- •Control Abstraction
- •Reducing code duplication
- •Simplifying client code
- •Currying
- •Writing new control structures
- •Conclusion
- •Composition and Inheritance
- •A two-dimensional layout library
- •Abstract classes
- •Extending classes
- •Invoking superclass constructors
- •Polymorphism and dynamic binding
- •Using composition and inheritance
- •Heighten and widen
- •Putting it all together
- •Conclusion
- •How primitives are implemented
- •Bottom types
- •Conclusion
- •Traits
- •How traits work
- •Thin versus rich interfaces
- •Example: Rectangular objects
- •The Ordered trait
- •Why not multiple inheritance?
- •To trait, or not to trait?
- •Conclusion
- •Packages and Imports
- •Putting code in packages
- •Concise access to related code
- •Imports
- •Implicit imports
- •Package objects
- •Conclusion
- •Assertions and Unit Testing
- •Assertions
- •Unit testing in Scala
- •Informative failure reports
- •Using JUnit and TestNG
- •Property-based testing
- •Organizing and running tests
- •Conclusion
- •Case Classes and Pattern Matching
- •A simple example
- •Kinds of patterns
- •Pattern guards
- •Pattern overlaps
- •Sealed classes
- •The Option type
- •Patterns everywhere
- •A larger example
- •Conclusion
- •Working with Lists
- •List literals
- •The List type
- •Constructing lists
- •Basic operations on lists
- •List patterns
- •First-order methods on class List
- •Methods of the List object
- •Processing multiple lists together
- •Conclusion
- •Collections
- •Sequences
- •Sets and maps
- •Selecting mutable versus immutable collections
- •Initializing collections
- •Tuples
- •Conclusion
- •Stateful Objects
- •What makes an object stateful?
- •Reassignable variables and properties
- •Case study: Discrete event simulation
- •A language for digital circuits
- •The Simulation API
- •Circuit Simulation
- •Conclusion
- •Type Parameterization
- •Functional queues
- •Information hiding
- •Variance annotations
- •Checking variance annotations
- •Lower bounds
- •Contravariance
- •Object private data
- •Upper bounds
- •Conclusion
- •Abstract Members
- •A quick tour of abstract members
- •Type members
- •Abstract vals
- •Abstract vars
- •Initializing abstract vals
- •Abstract types
- •Path-dependent types
- •Structural subtyping
- •Enumerations
- •Case study: Currencies
- •Conclusion
- •Implicit Conversions and Parameters
- •Implicit conversions
- •Rules for implicits
- •Implicit conversion to an expected type
- •Converting the receiver
- •Implicit parameters
- •View bounds
- •When multiple conversions apply
- •Debugging implicits
- •Conclusion
- •Implementing Lists
- •The List class in principle
- •The ListBuffer class
- •The List class in practice
- •Functional on the outside
- •Conclusion
- •For Expressions Revisited
- •For expressions
- •The n-queens problem
- •Querying with for expressions
- •Translation of for expressions
- •Going the other way
- •Conclusion
- •The Scala Collections API
- •Mutable and immutable collections
- •Collections consistency
- •Trait Traversable
- •Trait Iterable
- •Sets
- •Maps
- •Synchronized sets and maps
- •Concrete immutable collection classes
- •Concrete mutable collection classes
- •Arrays
- •Strings
- •Performance characteristics
- •Equality
- •Views
- •Iterators
- •Creating collections from scratch
- •Conversions between Java and Scala collections
- •Migrating from Scala 2.7
- •Conclusion
- •The Architecture of Scala Collections
- •Builders
- •Factoring out common operations
- •Integrating new collections
- •Conclusion
- •Extractors
- •An example: extracting email addresses
- •Extractors
- •Patterns with zero or one variables
- •Variable argument extractors
- •Extractors and sequence patterns
- •Extractors versus case classes
- •Regular expressions
- •Conclusion
- •Annotations
- •Why have annotations?
- •Syntax of annotations
- •Standard annotations
- •Conclusion
- •Working with XML
- •Semi-structured data
- •XML overview
- •XML literals
- •Serialization
- •Taking XML apart
- •Deserialization
- •Loading and saving
- •Pattern matching on XML
- •Conclusion
- •Modular Programming Using Objects
- •The problem
- •A recipe application
- •Abstraction
- •Splitting modules into traits
- •Runtime linking
- •Tracking module instances
- •Conclusion
- •Object Equality
- •Equality in Scala
- •Writing an equality method
- •Recipes for equals and hashCode
- •Conclusion
- •Combining Scala and Java
- •Using Scala from Java
- •Annotations
- •Existential types
- •Using synchronized
- •Compiling Scala and Java together
- •Conclusion
- •Actors and Concurrency
- •Trouble in paradise
- •Actors and message passing
- •Treating native threads as actors
- •Better performance through thread reuse
- •Good actors style
- •A longer example: Parallel discrete event simulation
- •Conclusion
- •Combinator Parsing
- •Example: Arithmetic expressions
- •Running your parser
- •Basic regular expression parsers
- •Another example: JSON
- •Parser output
- •Implementing combinator parsers
- •String literals and regular expressions
- •Lexing and parsing
- •Error reporting
- •Backtracking versus LL(1)
- •Conclusion
- •GUI Programming
- •Panels and layouts
- •Handling events
- •Example: Celsius/Fahrenheit converter
- •Conclusion
- •The SCells Spreadsheet
- •The visual framework
- •Disconnecting data entry and display
- •Formulas
- •Parsing formulas
- •Evaluation
- •Operation libraries
- •Change propagation
- •Conclusion
- •Scala Scripts on Unix and Windows
- •Glossary
- •Bibliography
- •About the Authors
- •Index
Foreword
I’m not sure where I first came across the Scala language. Maybe on a forum for programming language enthusiasts such as Lambda the Ultimate, or maybe in more pedestrian quarters: Reddit, or the like. Although I was intrigued at first blush, I owe my deeper exploration and enthusiasm for the language to two individuals: David Pollak, creator of the Lift web framework, and Steve Jenson, a former colleague at Twitter and generally brilliant programmer.
Following David and Steve, I arrived to Scala in the late-middle stage of the language’s history to date. By 2008, Scala had spent five years evolving from its initial release, and had formed around it a tight-knit community of academics, tinkerers, and even a few consultants. The mailing lists were full of spirited debates, announcements of exciting libraries, and a general camaraderie and shared joy for seeing what this powerful new tool could do. What Scala lacked, at that point, was a collection of success stories around major production deployments.
The decision to use Scala at Twitter, where I then worked, was not an easy one to make. Our infrastructure was buckling under the weight of extreme growth. Picking a relative unknown as our language of choice for building the high-performance distributed systems that would keep our fledgling service alive was risky. Still, the benefits that Scala offered were (and are) compelling, and our engineers were quickly able to produce prototypes that proved out the language’s effectiveness.
In the intervening time, I’ve seen a heartening number of companies large and small adopting Scala. In that time, too, the question of Scala’s complexity has been raised. From the outside, Scala’s many features might appear to be a kind of complexity. To understand Scala, though, is to understand its goal of being a scalable language. You can be writing real-world code in Scala in an afternoon. As your understanding of the language and, indeed,
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Foreword |
xxxv |
of the art and science of programming as a whole expands, there’s more of Scala there to wield to your advantage. That’s not complexity. It’s flexibility.
To be clear: Scala will challenge you. That’s part of the joy of using it. You won’t understand the full power of its type system by the end of your first day. You won’t understand the zen of objects being functions and functions being objects in your first week. Each feature of the language is another light bulb waiting to switch on over your head. I’m certain you’ll enjoy the experience of being gradually illuminated as you read this book and write code. I’ve watched programmers learn Scala on the job and succeed. It can be done, and it can be fun.
As Scala programmers like me have grown to better understand what this powerful language can do, so too has Scala evolved to meet programmers’ needs. Scala 2.8 smoothes out some rough spots in the collection libraries and adds useful features like named and default arguments to methods. While Scala has been a perfectly productive language to work with for some time, as of 2.8 it feels even more solid and polished. The new 2.8 release is icing on the cake.
In my experience, Scala was ready for production deployments two years ago. Today, it’s even better, and I can’t imagine building a new system without it. Presently, I’m doing just that. For me, Scala has gone from being a risky gamble to a trusted tool in two short years. I look forward to taking advantage of the latest features in Scala 2.8, and to using this book as the definitive reference for it, direct from the creator of the language I’ve grown to depend on.
Alex Payne
Portland, Oregon
October 27, 2010
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Foreword to the First Edition
Martin Odersky made a huge impact on the Java world with his design of the Pizza language. Although Pizza itself never became popular, it demonstrated that object-oriented and functional language features, when combined with skill and taste, form a natural and powerful combination. Pizza’s design became the basis for generics in Java, and Martin’s GJ (Generic Java) compiler was Sun Microsystem’s standard compiler starting in 1.3 (though with generics disabled). I had the pleasure of maintaining this compiler for a number of years, so I can report from first-hand experience that Martin’s skill in language design extends to language implementation.
Since that time, we at Sun tried to simplify program development by extending the language with piecemeal solutions to particular problems, like the for-each loop, enums, and autoboxing. Meanwhile, Martin continued his work on more powerful orthogonal language primitives that allow programmers to provide solutions in libraries.
Lately, there has been a backlash against statically typed languages. Experience with Java has shown that programming in a static language results in an abundance of boilerplate. The common wisdom is that one must abandon static typing to eliminate the boilerplate, and there is a rising interest in dynamic languages such as Python, Ruby, and Groovy. This common wisdom is debunked by the existence of Martin’s latest brainchild, Scala.
Scala is a tastefully typed language: it is statically typed, but explicit types appear in just the right places. Scala takes powerful features from object-oriented and functional languages, and combines them with a few novel ideas in a beautifully coherent whole. The syntax is so lightweight, and its primitives so expressive, that APIs can be used with virtually no syntactic overhead at all. Examples can be found in standard libraries such as parser combinators and actors. In this sense Scala supports embedded domain-specific languages.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Foreword to the First Edition |
xxxvii |
Will Scala be the next great language? Only time will tell. Martin Odersky’s team certainly has the taste and skill for the job. One thing is sure: Scala sets a new standard against which future languages will be measured.
Neal Gafter
San Jose, California
September 3, 2008
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index