Odersky M. Programming in Scala
Подождите немного. Документ загружается.
Glossary 721
is declared to be covariant in its lone type parameter (i.e., List is
declared List[+A]), List[Cat] is a subtype of List[Animal], and
List[Apple] a subtype of List[Fruit]. These subtype relationships
exist even though the class of each of these types is List. By contrast,
because Set is not declared to be covariant in its type parameter (i.e.,
Set is declared Set[A] with no plus sign), Set[Cat] is not a subtype
of Set[Animal]. A subtype should correctly implement the contracts
of its supertypes, so that the Liskov Substitution Principle applies, but
the compiler only verifies this property at the level of type checking.
superclass A class’s superclasses include its direct superclass, its direct su-
perclass’s direct superclass, and so on, all the way up to Any.
supertrait A class’s or trait’s supertraits, if any, include all traits directly
mixed into the class or trait or any of its superclasses, plus any super-
traits of those traits.
supertype A type is a supertype of all of its subtypes.
synthetic class A synthetic class is generated automatically by the compiler
rather than being written by hand by the programmer.
tail recursive A function is tail recursive if the only place the function calls
itself is the last operation of the function.
target typing Target typing is a form of type inference that takes into ac-
count the type that’s expected. In nums.filter((x) => x > 0), for
example, the Scala compiler infers type of x to be the element type of
nums, because the filter method invokes the function on each ele-
ment of nums.
template A template is the body of a class, trait, or singleton object defi-
nition. It defines the type signature, behavior and initial state of the
class, trait, or object.
trait A trait, which is defined with the trait keyword, is like an abstract
class that cannot take any value parameters and can be “mixed into”
classes or other traits via the process known as mixin composition.
When a trait is being mixed into a class or trait, it is called a mixin. A
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Glossary 722
trait may be parameterized with one or more types. When parameter-
ized with types, the trait constructs a type. For example, Set is a trait
that takes a single type parameter, whereas Set[Int] is a type. Also,
Set is said to be “the trait of” type Set[Int].
type Every variable and expression in a Scala program has a type that is
known at compile time. A type restricts the possible values to which
a variable can refer, or an expression can produce, at run time. A vari-
able or expression’s type can also be referred to as a static type if nec-
essary to differentiate it from an object’s runtime type. In other words,
“type” by itself means static type. Type is distinct from class because
a class that takes type parameters can construct many types. For ex-
ample, List is a class, but not a type. List[T] is a type with a free
type parameter. List[Int] and List[String] are also types (called
ground types because they have no free type parameters). A type can
have a “class” or “trait.” For example, the class of type List[Int] is
List. The trait of type Set[String] is Set.
type constraint Some annotations are type constraints, meaning that they
add additional limits, or constraints, on what values the type includes.
For example, @positive could be a type constraint on the type Int,
limiting the type of 32-bit integers down to those that are positive.
Type constraints are not checked by the standard Scala compiler, but
must instead be checked by an extra tool or by a compiler plugin.
type constructor A class or trait that takes type parameters.
type parameter A parameter to a generic class or generic method that must
be filled in by a type. For example, class List is defined as “class
List[T] { . . . ”, and method identity, a member of object Predef,
is defined as “def identity[T](x:T) = x”. The T in both cases is a
type parameter.
type signature A method’s type signature comprises its name, the number,
order, and types of its parameters, if any, and its result type. The type
signature of a class, trait, or singleton object comprises its name, the
type signatures of all of its members and constructors, and its declared
inheritance and mixin relations.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Glossary 723
uniform access principle The uniform access principle states that variables
and parameterless functions should be accessed using the same syntax.
Scala supports this principle by not allowing parentheses to be placed
at call sites of parameterless functions. As a result, a parameterless
function definition can be changed to a val, or vice versa, without
affecting client code.
unreachable At the Scala level, objects can become unreachable, at which
point the memory they occupy may be reclaimed by the runtime. Un-
reachable does not necessarily mean unreferenced. Reference types
(instances of AnyRef) are implemented as objects that reside on the
JVM’s heap. When an instance of a reference type becomes unreach-
able, it indeed becomes unreferenced, and is available for garbage col-
lection. Value types (instances of AnyVal) are implemented as both
primitive type values and as instances of Java wrapper types (such as
java.lang.Integer), which reside on the heap. Value type instances
can be boxed (converted from a primitive value to a wrapper object)
and unboxed (converted from a wrapper object to a primitive value)
throughout the lifetime of the variables that refer to them. If a value
type instance currently represented as a wrapper object on the JVM’s
heap becomes unreachable, it indeed becomes unreferenced, and is
available for garbage collection. But if a value type currently repre-
sented as a primitive value becomes unreachable, then it does not be-
come unreferenced, because it does not exist as an object on the JVM’s
heap at that point in time. The runtime may reclaim memory occupied
by unreachable objects, but if an Int, for example, is implemented
at run time by a primitive Java int that occupies some memory in the
stack frame of an executing method, then the memory for that object is
“reclaimed” when the stack frame is popped as the method completes.
Memory for reference types, such as Strings, may be reclaimed by
the JVM’s garbage collector after they become unreachable.
unreferenced See unreachable.
value The result of any computation or expression in Scala is a value, and
in Scala, every value is an object. The term value essentially means
the image of an object in memory (on the JVM’s heap or stack).
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Glossary 724
value type A value type is any subclass of AnyVal, such as Int, Double, or
Unit. This term has meaning at the level of Scala source code. At run-
time, instances of value types that correspond to Java primitive types
may be implemented in terms of primitive type values or instances of
wrapper types, such as java.lang.Integer. Over the lifetime of a
value type instance, the runtime may transform it back and forth be-
tween primitive and wrapper types (i.e., to box and unbox it).
variable A named entity that refers to an object. A variable is either a val
or a var. Both vals and vars must be initialized when defined, but
only vars can be later reassigned to refer to a different object.
variance A type parameter of a class or trait can be marked with a variance
annotation, either covariant (+) or contravariant (-). Such variance
annotations indicate how subtyping works for a generic class or trait.
For example, the generic class List is covariant in its type parameter,
and thus List[String] is a subtype of List[Any]. By default, i.e.,
absent a + or - annotation, type parameters are nonvariant.
yield An expression can yield a result. The yield keyword designates the
result of a for expression.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Bibliography
[Abe96] Abelson, Harold and Gerald Jay Sussman. Structure and Inter-
pretation of Computer Programs. The MIT Press, second edition,
1996.
[Aho86] Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers:
Principles, Techniques, and Tools. Addison-Wesley Longman Pub-
lishing Co., Inc., Boston, MA, USA, 1986. ISBN 0-201-10088-6.
[Blo08] Bloch, Joshua. Effective Java Second Edition. Addison-Wesley,
2008.
[DeR75] DeRemer, Frank and Hans Kron. “Programming-in-the large ver-
sus programming-in-the-small.” In Proceedings of the international
conference on Reliable software, pages 114–121. ACM, New York,
NY, USA, 1975. doi:http://doi.acm.org/10.1145/800027.808431.
[Dij70] Dijkstra, Edsger W. “Notes on Structured Programming.”, April
1970. Circulated privately. Available at http://www.cs.utexas.edu
/users/EWD/ewd02xx/EWD249.PDF as EWD249 (accessed June 6,
2008).
[Eck98] Eckel, Bruce. Thinking in Java. Prentice Hall, 1998.
[Emi07] Emir, Burak, Martin Odersky, and John Williams. “Matching Ob-
jects With Patterns.” In Proc. ECOOP, Springer LNCS, pages 273–
295. July 2007.
[Eva03] Evans, Eric. Domain-Driven Design: Tackling Complexity in the
Heart of Software. Addison-Wesley Professional, 2003.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Bibliography 726
[Fow04] Fowler, Martin. “Inversion of Control Containers and the Depen-
dency Injection pattern.” January 2004. Available on the web at
http://martinfowler.com/articles/injection.html (accesssed August 6,
2008).
[Gam95] Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides.
Design Patterns : Elements of Reusable Object-Oriented Software.
Addison-Wesley, 1995.
[Goe06] Goetz, Brian, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David
Homes, and Doug Lea. Java Concurrency in Practice. Addison
Wesley, 2006.
[Jav] The Java Tutorials: Creating a GUI with JFC/Swing. Available on
the web at http://java.sun.com/docs/books/tutorial/uiswing.
[Kay96] Kay, Alan C. “The Early History of Smalltalk.” In History of
programming languages—II, pages 511–598. ACM, New York, NY,
USA, 1996. ISBN 0-201-89502-1. doi:http://doi.acm.org/10.1145/
234286.1057828.
[Kay03] Kay, Alan C. An email to Stefan Ram on the meaning of the term
“object-oriented programming”, July 2003. The email is published
on the web at http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
(accesssed June 6, 2008).
[Lan66] Landin, Peter J. “The Next 700 Programming Languages.” Com-
munications of the ACM, 9(3):157–166, 1966.
[Mey91] Meyers, Scott. Effective C++. Addison-Wesley, 1991.
[Mey00] Meyer, Bertrand. Object-Oriented Software Construction. Prentice
Hall, 2000.
[Ode03] Odersky, Martin, Vincent Cremet, Christine Röckl, and Matthias
Zenger. “A Nominal Theory of Objects with Dependent Types.” In
Proc. ECOOP’03, Springer LNCS, pages 201–225. July 2003.
[Ode05] Odersky, Martin and Matthias Zenger. “Scalable Component Ab-
stractions.” In Proceedings of OOPSLA, pages 41–58. October
2005.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Bibliography 727
[Ode08] Odersky, Martin. The Scala Language Specification,
Version 2.7. EPFL, February 2008. Http://www.scala-
lang.org/docu/manuals.html.
[Ray99] Raymond, Eric. The Cathedral & the Bazaar: Musings on Linux
and Open Source by an Accidental Revolutionary. O’Reilly, 1999.
[Rum04] Rumbaugh, James, Ivar Jacobson, and Grady Booch. The Uni-
fied Modeling Language Reference Manual (2nd Edition). Addison-
Wesley, 2004.
[SPJ02] Simon Peyton Jones, et.al. “Haskell 98 Language
and Libraries, Revised Report.” Technical report,
http://www.haskell.org/onlinereport, 2002.
[Ste99] Steele, Jr., Guy L. “Growing a Language.” Higher-Order and Sym-
bolic Computation, 12:221–223, 1999. Transcript of a talk given at
OOPSLA 1998.
[Vaz07] Vaziri, Mandana, Frank Tip, Stephen Fink, and Julian Dolby.
“Declarative Object Identity Using Relation Types.” In Proc.
ECOOP 2007, pages 54–78. 2007.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
About the Authors
Martin Odersky is the creator of the Scala language. As a professor at
EPFL in Lausanne, Switzerland, he works on programming languages, more
specifically languages for object-oriented and functional programming. His
research thesis is that the two paradigms are two sides of the same coin, to
be unified as much as possible. To prove this, he has experimented with a
number of language designs, from Pizza to GJ to Functional Nets. He has
also influenced the development of Java as a co-designer of Java generics
and as the original author of the current javac reference compiler. Since
2001 he has concentrated on designing, implementing, and refining the Scala
programming language.
Lex Spoon is a software engineer at Google, Inc. He worked on Scala for
two years as a post-doc at EPFL. He has a Ph.D. in computer science from
Georgia Tech, where he worked on static analysis of dynamic languages.
In addition to Scala, he has worked on a wide variety of programming lan-
guages, ranging from the dynamic language Smalltalk to the scientific lan-
guage X10. He and his wife currently live in Atlanta with two cats, a chi-
huahua, and a turtle.
Bill Venners is president of Artima, Inc., publisher of the Artima Devel-
oper website (www.artima.com). He is author of the book, Inside the Java
Virtual Machine, a programmer-oriented survey of the Java platform’s archi-
tecture and internals. His popular columns in JavaWorld magazine covered
Java internals, object-oriented design, and Jini. Active in the Jini Community
since its inception, Bill led the Jini Community’s ServiceUI project, whose
ServiceUI API became the de facto standard way to associate user interfaces
to Jini services. Bill is also the lead developer and designer of ScalaTest, an
open source testing tool for Scala and Java developers.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Index
Page numbers followed by an n refer
to footnotes.
Symbols
! (invert)
on class Boolean, 120
! (message send)
on trait Actor, 43, 610–612
!= (not equals)
method on Any, 123, 237
" (string delimiter), 113
""" (raw string delimiter), 113
’ (character delimiter), 111
() (empty parentheses)
on method definitions, 212
() (unit value), 152
*
(repeat)
on class String, 91
*
(repeated parameter), 188
*
(times)
on numeric types, 118
**
(intersect)
on trait collection.Set, 370
+ (add element)
on traits mutable.Map and
immutable.Map, 372
on traits mutable.Set and
immutable.Set, 82, 370
+ (covariant in)
List’s type parameter, 488
variance annotation, 418
+ (plus)
on numeric types, 118
++ (add elements)
on traits mutable.Map and
immutable.Map, 372
on traits mutable.Set and
immutable.Set, 370
++= (add elements to)
on trait mutable.Map, 373
on trait mutable.Set, 370
+: (prepend)
on class ListBuffer, 363
+= (add element to)
on trait mutable.Map, 373
on trait mutable.Set, 370
+= (add to)
on trait mutable.Set, 82
reassignment with immutable
sets and vars, 83
+= (append)
on class ArrayBuffer, 364
on class ListBuffer, 363, 494
- (contravariant in)
variance annotation, 418
- (minus)
on numeric types, 118
- (remove element)
on traits mutable.Map and
immutable.Map, 372
on traits mutable.Set and
immutable.Set, 370
-- (remove elements)
729
Index 730
on traits mutable.Map and
immutable.Map, 372
on traits mutable.Set and
immutable.Set, 370
--= (remove elements from)
on trait mutable.Map, 373
on trait mutable.Set, 370
-= (remove element from)
on trait mutable.Map, 373
on trait mutable.Set, 370
-> (map to), 85
in implicit conversion, 475
/ (divided by)
on numeric types, 118
/: (fold left)
on class List, 348
: (colon)
in type annotations, 60
:: (cons) class
as pattern constructor, 331
subclass of List, 487–490
:: (cons) method
on class List, 76, 328
right associativity of, 77, 329
::: (concatenation)
on class List, 76, 332, 489
:\ (fold right)
on class List, 348
; (semicolon)
inference, 98
< (less than)
on numeric types, 119
<- (in)
in for expressions, 69
<: (upper bound), 433
<< (shift left)
on integral types, 122
<= (less than or equal to)
on numeric types, 119
<% (view bound), 483
= (variable assignment), 60
== (equals)
in set membership, 368
== (equals)
in Scala versus Java, 124
in-depth treatment, 568–593
method on Any, 123, 237, 568
quick introduction, 123–124
=== (triple equals)
in ScalaTest suites, 282
=> (right arrow, or “rocket”)
in function literals, 68
in import statements, 270–271
in self types, 563
in match alternatives, 164
in this aliasing, 659
> (greater than)
on numeric types, 119
>: (lower bound), 425
>= (greater than or equal to)
on numeric types, 119
>> (shift right)
on integral types, 122
>>> (unsigned shift right)
on integral types, 122
@ (at sign)
in annotations, 533
to extract XML attributes, 546
# (pound sign)
in inner class type names, 451
$tag method
on trait ScalaObject, 241
% (remainder)
on numeric types, 118
& (bitwise-and)
on integral types, 121
&& (logical-and)
on class Boolean, 120
_ (underscore)
in curried functions, 202
in existential types, 586
in function literals, 180, 197
in identifiers, 142
in import statements, 271
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index