{{ content }}
- {% include tutorial-pager.txt %}
+ {% include pager.txt %}
{% if page.disqus == true %}{% include disqus.txt %}{% endif %}
-
+
{% include tutorial-toc.txt %}
-
+
-{% include footer.txt %}
+{% include footer.txt %}
diff --git a/es/tutorials/tour/singleton-objects.md b/es/tutorials/tour/singleton-objects.md
index 5acb50ecd9..34bd46c84b 100644
--- a/es/tutorials/tour/singleton-objects.md
+++ b/es/tutorials/tour/singleton-objects.md
@@ -7,8 +7,8 @@ disqus: true
tutorial: scala-tour
num: 12
language: es
-tutorial-next: xml-processing
-tutorial-previous: pattern-matching
+next-page: xml-processing
+previous-page: pattern-matching
---
Métodos y valores que no están asociados con instancias individuales de una [clase](classes.html) se denominan *objetos singleton* y se denotan con la palabra reservada `object` en vez de `class`.
diff --git a/style/control-structures.md b/style/control-structures.md
index 2874d029ea..3107418452 100644
--- a/style/control-structures.md
+++ b/style/control-structures.md
@@ -4,6 +4,9 @@ title: Control Structures
partof: style-guide
num: 7
+
+previous-page: files
+next-page: method-invocation
---
All control structures should be written with a space following the
@@ -13,7 +16,7 @@ defining keyword:
if (foo) bar else baz
for (i <- 0 to 10) { ... }
while (true) { println("Hello, World!") }
-
+
// wrong!
if(foo) bar else baz
for(i <- 0 to 10) { ... }
@@ -37,7 +40,7 @@ Remember the following guidelines:
only a single line.
- `case` - Always omit braces in case clauses.
-
+
val news = if (foo)
goodNews()
@@ -60,7 +63,7 @@ one generator (usually, more than one `<-` symbol). In such cases, there
are two alternative syntaxes which may be used:
// wrong!
- for (x <- board.rows; y <- board.files)
+ for (x <- board.rows; y <- board.files)
yield (x, y)
// right!
diff --git a/style/declarations.md b/style/declarations.md
index 7f5825ed5e..0960308418 100644
--- a/style/declarations.md
+++ b/style/declarations.md
@@ -3,7 +3,10 @@ layout: overview-large
title: Declarations
partof: style-guide
-num: 6
+num: 9
+
+previous-page: method-invocation
+next-page: scaladoc
---
## Classes
@@ -37,7 +40,7 @@ constructor arguments and extensions:
birthdate: Date,
astrologicalSign: String,
shoeSize: Int,
- favoriteColor: java.awt.Color)
+ favoriteColor: java.awt.Color)
extends Entity
with Logging
with Identifiable
@@ -114,14 +117,14 @@ applicable):
4. Final modifier (`final`)
5. `def`
-
+
@Transaction
@throws(classOf[IOException])
- override protected final def foo() {
+ override protected final def foo() {
...
}
-
+
#### Body
When a method body comprises a single expression which is less than 30
@@ -186,7 +189,7 @@ There are three main reasons you should do this:
structures":
def unless(exp: Boolean)(code: => Unit): Unit = if (!exp) code
- unless(x < 5) {
+ unless(x < 5) {
println("x was not less than five")
}
@@ -217,7 +220,7 @@ open-paren of the parameter lists, one list per line (i.e. if you can't
put them all on one line, put one each per line):
protected def forResource(resourceInfo: Any)
- (f: (JsonNode) => Any)
+ (f: (JsonNode) => Any)
(implicit urlCreator: URLCreator, configurer: OAuthConfiguration): Any = {
...
}
@@ -275,11 +278,11 @@ function value.
When styles (1) and (4) are used exclusively, it becomes very easy to
distinguish places in the source code where function values are used.
Both styles make use of parentheses, since they look clean on a single line.
-
+
### Spacing
There should be no space between parentheses and the code they contain.
-Curly braces should be separated from the code within them by a one-space gap,
+Curly braces should be separated from the code within them by a one-space gap,
to give the visually busy braces "breathing room".
### Multi-Expression Functions
@@ -287,8 +290,8 @@ to give the visually busy braces "breathing room".
Most function values are less trivial than the examples given above.
Many contain more than one expression. In such cases, it is often more
readable to split the function value across multiple lines. When this
-happens, only style (1) should be used, substituting braces for parentheses.
-Style (4) becomes extremely difficult to follow when enclosed in large amounts
+happens, only style (1) should be used, substituting braces for parentheses.
+Style (4) becomes extremely difficult to follow when enclosed in large amounts
of code. The declaration itself should loosely follow the declaration style for
methods, with the opening brace on the same line as the assignment or
invocation, while the closing brace is on its own line immediately
diff --git a/style/files.md b/style/files.md
index 79a89bd359..5a14b53006 100644
--- a/style/files.md
+++ b/style/files.md
@@ -3,7 +3,10 @@ layout: overview-large
title: Files
partof: style-guide
-num: 9
+num: 6
+
+previous-page: nested-blocks
+next-page: control-structures
---
As a rule, files should contain a *single* logical compilation unit. By
@@ -63,4 +66,3 @@ declarations. These filenames may be based upon a significant type which
they contain (e.g. `option.scala` for the example above), or may be
descriptive of the logical property shared by all units within (e.g.
`ast.scala`).
-
diff --git a/style/indentation.md b/style/indentation.md
index ad6a086dcb..701b447d5e 100644
--- a/style/indentation.md
+++ b/style/indentation.md
@@ -4,6 +4,9 @@ title: Indentation
partof: style-guide
num: 2
+
+previous-page: overview
+next-page: naming-conventions
---
Indentation should follow the "2-space convention". Thus, instead of
diff --git a/style/method-invocation.md b/style/method-invocation.md
index 622f2a43d2..13dc3c7f2e 100644
--- a/style/method-invocation.md
+++ b/style/method-invocation.md
@@ -4,6 +4,9 @@ title: Method Invocation
partof: style-guide
num: 8
+
+previous-page: control-structures
+next-page: declarations
---
Generally speaking, method invocation in Scala follows Java conventions.
@@ -62,14 +65,14 @@ Scala allows methods of arity-0 to be invoked using suffix notation:
names toList // Unsafe, don't use!
This style is unsafe, and should not be used. Since semicolons are
-optional, the compiler will attempt to treat it as an infix method
+optional, the compiler will attempt to treat it as an infix method
if it can, potentially taking a term from the next line.
names toList
val answer = 42 // will not compile!
-This may result in unexpected compile errors at best, and happily
-compiled faulty code at worst. Although the syntax is used by some
+This may result in unexpected compile errors at best, and happily
+compiled faulty code at worst. Although the syntax is used by some
DSLs, it should be considered deprecated, and avoided.
As of Scala 2.10, using suffix operator notation will result in a compiler warning.
@@ -152,4 +155,3 @@ Finally, the use of the `/:` and `:\` should be avoided in preference to
the more explicit `foldLeft` and `foldRight` method of `Iterator`. The
right-associativity of the `/:` can lead to extremely confusing code, at
the benefit of saving a few characters.
-
diff --git a/style/naming-conventions.md b/style/naming-conventions.md
index 7c9c1e65e5..cf685461cd 100644
--- a/style/naming-conventions.md
+++ b/style/naming-conventions.md
@@ -4,6 +4,9 @@ title: Naming Conventions
partof: style-guide
num: 3
+
+previous-page: indentation
+next-page: types
---
Generally speaking, Scala uses "camel case" naming. That is,
diff --git a/style/nested-blocks.md b/style/nested-blocks.md
index 62ca31933c..45e38c6ac2 100644
--- a/style/nested-blocks.md
+++ b/style/nested-blocks.md
@@ -4,6 +4,9 @@ title: Nested Blocks
partof: style-guide
num: 5
+
+previous-page: types
+next-page: files
---
## Curly Braces
@@ -31,13 +34,13 @@ lines as their content (Lisp-style):
(this + is a very ++ long *
expression)
-Parentheses also serve to disable semicolon inference, and so allow the developer
+Parentheses also serve to disable semicolon inference, and so allow the developer
to start lines with operators, which some prefer:
-
+
( someCondition
|| someOtherCondition
|| thirdCondition
)
-
-A trailing parenthesis on the following line is acceptable in this case, for
+
+A trailing parenthesis on the following line is acceptable in this case, for
aesthetic reasons.
diff --git a/style/overview.md b/style/overview.md
index 4260b8df11..e813e46182 100644
--- a/style/overview.md
+++ b/style/overview.md
@@ -1,9 +1,12 @@
---
layout: overview-large
title: Overview
+
partof: style-guide
num: 1
outof: 10
+
+next-page: indentation
---
-Please see the [table of contents of the style guide]({{ site.baseurl }}/style) for an outline-style overview.
\ No newline at end of file
+Please see the [table of contents of the style guide]({{ site.baseurl }}/style) for an outline-style overview.
diff --git a/style/scaladoc.md b/style/scaladoc.md
index f153f7ce68..2687e8fb6b 100644
--- a/style/scaladoc.md
+++ b/style/scaladoc.md
@@ -4,6 +4,8 @@ title: Scaladoc
partof: style-guide
num: 10
+
+previous-page: declarations
---
It is important to provide documentation for all packages, classes,
@@ -22,9 +24,9 @@ experienced users, but can be invaluable for newcomers).
The general format for a Scaladoc comment should be as follows:
/** This is a brief description of what's being documented.
- *
+ *
* This is further documentation of what we're documenting. It should
- * provide more details as to how this works and what it does.
+ * provide more details as to how this works and what it does.
*/
def myMethod = {}
@@ -109,21 +111,21 @@ notation:
package my.package
/** Provides classes for dealing with complex numbers. Also provides
* implicits for converting to and from `Int`.
- *
+ *
* ==Overview==
* The main class to use is [[my.package.complex.Complex]], as so
* {{ "{{{" }}
* scala> val complex = Complex(4,3)
* complex: my.package.complex.Complex = 4 + 3i
* }}}
- *
- * If you include [[my.package.complex.ComplexConversions]], you can
+ *
+ * If you include [[my.package.complex.ComplexConversions]], you can
* convert numbers more directly
* {{ "{{{" }}
* scala> import my.package.complex.ComplexConversions._
* scala> val complex = 4 + 3.i
* complex: my.package.complex.Complex = 4 + 3i
- * }}}
+ * }}}
*/
package complex {}
@@ -146,10 +148,10 @@ If the class should be created using a constructor, document it using
the `@constructor` syntax:
/** A person who uses our application.
- *
+ *
* @constructor create a new person with a name and age.
* @param name the person's name
- * @param age the person's age in years
+ * @param age the person's age in years
*/
class Person(name: String, age: Int) {
}
@@ -169,18 +171,18 @@ sure to indicate the actual method names:
/** Factory for [[mypackage.Person]] instances. */
object Person {
/** Creates a person with a given name and age.
- *
+ *
* @param name their name
- * @param age the age of the person to create
+ * @param age the age of the person to create
*/
def apply(name: String, age: Int) = {}
/** Creates a person with a given name and birthdate
- *
+ *
* @param name their name
* @param birthDate the person's birthdate
- * @return a new Person instance with the age determined by the
- * birthdate and current date.
+ * @return a new Person instance with the age determined by the
+ * birthdate and current date.
*/
def apply(name: String, birthDate: java.util.Date) = {}
}
@@ -189,11 +191,11 @@ If your object holds implicit conversions, provide an example in the
Scaladoc:
/** Implicit conversions and helpers for [[mypackage.Complex]] instances.
- *
+ *
* {{ "{{{" }}
* import ComplexImplicits._
* val c: Complex = 4 + 3.i
- * }}}
+ * }}}
*/
object ComplexImplicits {}
diff --git a/style/types.md b/style/types.md
index de71804921..878c75dc2c 100644
--- a/style/types.md
+++ b/style/types.md
@@ -4,27 +4,30 @@ title: Types
partof: style-guide
num: 4
+
+previous-page: naming-conventions
+next-page: nested-blocks
---
## Inference
-Use type inference where possible, but put clarity first, and favour
+Use type inference where possible, but put clarity first, and favour
explicitness in public APIs.
-You should almost never annotate the type of a private field or a local
+You should almost never annotate the type of a private field or a local
variable, as their type will usually be immediately evident in
their value:
private val name = "Daniel"
-However, you may wish to still display the type where the assigned value has a
-complex or non-obvious form.
-
-All public methods should have explicit type annotations. Type inference may
+However, you may wish to still display the type where the assigned value has a
+complex or non-obvious form.
+
+All public methods should have explicit type annotations. Type inference may
break encapsulation in these cases, because it depends on internal method
-and class details. Without an explicit type, a change to the internals
+and class details. Without an explicit type, a change to the internals
of a method or val could alter the public API of the class without warning,
-potentially breaking client code. Explicit type annotations can also help
+potentially breaking client code. Explicit type annotations can also help
to improve compile times.
### Function Values
@@ -137,7 +140,7 @@ by a semi-colon and a single space, the opening brace should be
*followed* by a space while the closing brace should be *preceded* by a
space (as demonstrated in both examples above).
-Structural types are implemented with reflection at runtime, and are
-inherently less performant than nominal types. Developers should
-prefer the use of nominal types, unless structural types provide a
+Structural types are implemented with reflection at runtime, and are
+inherently less performant than nominal types. Developers should
+prefer the use of nominal types, unless structural types provide a
clear benefit.
diff --git a/tutorials/tour/abstract-types.md b/tutorials/tour/abstract-types.md
index 73bf8ff917..34165554a7 100644
--- a/tutorials/tour/abstract-types.md
+++ b/tutorials/tour/abstract-types.md
@@ -7,8 +7,8 @@ disqus: true
tutorial: scala-tour
num: 22
languages: [ba, es, ko]
-tutorial-next: compound-types
-tutorial-previous: inner-classes
+next-page: compound-types
+previous-page: inner-classes
---
In Scala, classes are parameterized with values (the constructor parameters) and with types (if classes are [generic](generic-classes.html)). For reasons of regularity, it is not only possible to have values as object members; types along with values are members of objects. Furthermore, both forms of members can be concrete and abstract.
diff --git a/tutorials/tour/annotations.md b/tutorials/tour/annotations.md
index 1319e66726..160e45c30c 100644
--- a/tutorials/tour/annotations.md
+++ b/tutorials/tour/annotations.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 31
-tutorial-next: default-parameter-values
-tutorial-previous: automatic-closures
+next-page: default-parameter-values
+previous-page: automatic-closures
---
Annotations associate meta-information with definitions.
diff --git a/tutorials/tour/anonymous-function-syntax.md b/tutorials/tour/anonymous-function-syntax.md
index 7d2f12138a..2206a7068d 100644
--- a/tutorials/tour/anonymous-function-syntax.md
+++ b/tutorials/tour/anonymous-function-syntax.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 6
-tutorial-next: higher-order-functions
-tutorial-previous: mixin-class-composition
+next-page: higher-order-functions
+previous-page: mixin-class-composition
---
Scala provides a relatively lightweight syntax for defining anonymous functions. The following expression creates a successor function for integers:
diff --git a/tutorials/tour/automatic-closures.md b/tutorials/tour/automatic-closures.md
index 4a487b272b..def13092f3 100644
--- a/tutorials/tour/automatic-closures.md
+++ b/tutorials/tour/automatic-closures.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 30
-tutorial-next: annotations
-tutorial-previous: operators
+next-page: annotations
+previous-page: operators
---
Scala allows parameterless function names as parameters of methods. When such a method is called, the actual parameters for parameterless function names are not evaluated and a nullary function is passed instead which encapsulates the computation of the corresponding parameter (so-called *call-by-name* evalutation).
diff --git a/tutorials/tour/case-classes.md b/tutorials/tour/case-classes.md
index d58842e432..f5d58033b6 100644
--- a/tutorials/tour/case-classes.md
+++ b/tutorials/tour/case-classes.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 10
-tutorial-next: pattern-matching
-tutorial-previous: currying
+next-page: pattern-matching
+previous-page: currying
---
Scala supports the notion of _case classes_. Case classes are just regular classes that are:
diff --git a/tutorials/tour/classes.md b/tutorials/tour/classes.md
index dadaffead7..c330aa92d9 100644
--- a/tutorials/tour/classes.md
+++ b/tutorials/tour/classes.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 3
-tutorial-next: traits
-tutorial-previous: unified-types
+next-page: traits
+previous-page: unified-types
---
Classes in Scala are static templates that can be instantiated into many objects at runtime.
diff --git a/tutorials/tour/compound-types.md b/tutorials/tour/compound-types.md
index ffa698be71..1411c53a19 100644
--- a/tutorials/tour/compound-types.md
+++ b/tutorials/tour/compound-types.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 23
-tutorial-next: explicitly-typed-self-references
-tutorial-previous: abstract-types
+next-page: explicitly-typed-self-references
+previous-page: abstract-types
---
Sometimes it is necessary to express that the type of an object is a subtype of several other types. In Scala this can be expressed with the help of *compound types*, which are intersections of object types.
diff --git a/tutorials/tour/currying.md b/tutorials/tour/currying.md
index a8ab2b3311..e237b35101 100644
--- a/tutorials/tour/currying.md
+++ b/tutorials/tour/currying.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 9
-tutorial-next: case-classes
-tutorial-previous: nested-functions
+next-page: case-classes
+previous-page: nested-functions
---
Methods may define multiple parameter lists. When a method is called with a fewer number of parameter lists, then this will yield a function taking the missing parameter lists as its arguments.
diff --git a/tutorials/tour/default-parameter-values.md b/tutorials/tour/default-parameter-values.md
index 5cd02d40ac..d1d64fbff3 100644
--- a/tutorials/tour/default-parameter-values.md
+++ b/tutorials/tour/default-parameter-values.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 32
-tutorial-next: named-parameters
-tutorial-previous: annotations
+next-page: named-parameters
+previous-page: annotations
---
Scala provides the ability to give parameters default values that can be used to allow a caller to omit those parameters.
diff --git a/tutorials/tour/explicitly-typed-self-references.md b/tutorials/tour/explicitly-typed-self-references.md
index 8c53793040..c4608d7437 100644
--- a/tutorials/tour/explicitly-typed-self-references.md
+++ b/tutorials/tour/explicitly-typed-self-references.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 24
-tutorial-next: implicit-parameters
-tutorial-previous: compound-types
+next-page: implicit-parameters
+previous-page: compound-types
---
When developing extensible software it is sometimes handy to declare the type of the value `this` explicitly. To motivate this, we will derive a small extensible representation of a graph data structure in Scala.
diff --git a/tutorials/tour/extractor-objects.md b/tutorials/tour/extractor-objects.md
index 736c1bf1af..d588e8ec9f 100644
--- a/tutorials/tour/extractor-objects.md
+++ b/tutorials/tour/extractor-objects.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 15
-tutorial-next: sequence-comprehensions
-tutorial-previous: regular-expression-patterns
+next-page: sequence-comprehensions
+previous-page: regular-expression-patterns
---
In Scala, patterns can be defined independently of case classes. To this end, a method named unapply is defined to yield a so-called extractor. An extractor can be thought of as a special method that reverses the effect of applying a particular object on some inputs. Its purpose is to 'extract' the inputs that were present before the 'apply' operation. For instance, the following code defines an extractor [object](singleton-objects.html) Twice.
diff --git a/tutorials/tour/generic-classes.md b/tutorials/tour/generic-classes.md
index 9005e43445..0160d8e08a 100644
--- a/tutorials/tour/generic-classes.md
+++ b/tutorials/tour/generic-classes.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 17
-tutorial-next: variances
-tutorial-previous: sequence-comprehensions
+next-page: variances
+previous-page: sequence-comprehensions
---
Like in Java 5 (aka. [JDK 1.5](http://java.sun.com/j2se/1.5/)), Scala has built-in support for classes parameterized with types. Such generic classes are particularly useful for the development of collection classes.
diff --git a/tutorials/tour/higher-order-functions.md b/tutorials/tour/higher-order-functions.md
index 03f16391e6..f721ff3500 100644
--- a/tutorials/tour/higher-order-functions.md
+++ b/tutorials/tour/higher-order-functions.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 7
-tutorial-next: nested-functions
-tutorial-previous: anonymous-function-syntax
+next-page: nested-functions
+previous-page: anonymous-function-syntax
---
Scala allows the definition of higher-order functions. These are functions that _take other functions as parameters_, or whose _result is a function_. Here is a function `apply` which takes another function `f` and a value `v` and applies function `f` to `v`:
diff --git a/tutorials/tour/implicit-conversions.md b/tutorials/tour/implicit-conversions.md
index 71db42e38a..71e1e192c3 100644
--- a/tutorials/tour/implicit-conversions.md
+++ b/tutorials/tour/implicit-conversions.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 26
-tutorial-next: polymorphic-methods
-tutorial-previous: implicit-parameters
+next-page: polymorphic-methods
+previous-page: implicit-parameters
---
An implicit conversion from type `S` to type `T` is defined by an implicit value which has function type `S => T`, or by an implicit method convertible to a value of that type.
diff --git a/tutorials/tour/implicit-parameters.md b/tutorials/tour/implicit-parameters.md
index 471b5e638e..53849af107 100644
--- a/tutorials/tour/implicit-parameters.md
+++ b/tutorials/tour/implicit-parameters.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 25
-tutorial-next: implicit-conversions
-tutorial-previous: explicitly-typed-self-references
+next-page: implicit-conversions
+previous-page: explicitly-typed-self-references
---
A method with _implicit parameters_ can be applied to arguments just like a normal method. In this case the implicit label has no effect. However, if such a method misses arguments for its implicit parameters, such arguments will be automatically provided.
diff --git a/tutorials/tour/inner-classes.md b/tutorials/tour/inner-classes.md
index bd05876b57..41d5b042e7 100644
--- a/tutorials/tour/inner-classes.md
+++ b/tutorials/tour/inner-classes.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 21
-tutorial-next: abstract-types
-tutorial-previous: lower-type-bounds
+next-page: abstract-types
+previous-page: lower-type-bounds
---
In Scala it is possible to let classes have other classes as members. Opposed to Java-like languages where such inner classes are members of the enclosing class, in Scala such inner classes are bound to the outer object. To illustrate the difference, we quickly sketch the implementation of a graph datatype:
diff --git a/tutorials/tour/local-type-inference.md b/tutorials/tour/local-type-inference.md
index b9afcb6915..2e8687b7f3 100644
--- a/tutorials/tour/local-type-inference.md
+++ b/tutorials/tour/local-type-inference.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 28
-tutorial-next: operators
-tutorial-previous: polymorphic-methods
+next-page: operators
+previous-page: polymorphic-methods
---
Scala has a built-in type inference mechanism which allows the programmer to omit certain type annotations. It is, for instance, often not necessary in Scala to specify the type of a variable, since the compiler can deduce the type from the initialization expression of the variable. Also return types of methods can often be omitted since they correspond to the type of the body, which gets inferred by the compiler.
diff --git a/tutorials/tour/lower-type-bounds.md b/tutorials/tour/lower-type-bounds.md
index a69cf5f445..ddf9e29917 100644
--- a/tutorials/tour/lower-type-bounds.md
+++ b/tutorials/tour/lower-type-bounds.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 20
-tutorial-next: inner-classes
-tutorial-previous: upper-type-bounds
+next-page: inner-classes
+previous-page: upper-type-bounds
---
While [upper type bounds](upper-type-bounds.html) limit a type to a subtype of another type, *lower type bounds* declare a type to be a supertype of another type. The term `T >: A` expresses that the type parameter `T` or the abstract type `T` refer to a supertype of type `A`.
diff --git a/tutorials/tour/mixin-class-composition.md b/tutorials/tour/mixin-class-composition.md
index 817cabd1fc..1740989692 100644
--- a/tutorials/tour/mixin-class-composition.md
+++ b/tutorials/tour/mixin-class-composition.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 5
-tutorial-next: anonymous-function-syntax
-tutorial-previous: traits
+next-page: anonymous-function-syntax
+previous-page: traits
---
As opposed to languages that only support _single inheritance_, Scala has a more general notion of class reuse. Scala makes it possible to reuse the _new member definitions of a class_ (i.e. the delta in relationship to the superclass) in the definition of a new class. This is expressed as a _mixin-class composition_. Consider the following abstraction for iterators.
diff --git a/tutorials/tour/named-parameters.md b/tutorials/tour/named-parameters.md
index 4fbbebf0ba..b3e15a984a 100644
--- a/tutorials/tour/named-parameters.md
+++ b/tutorials/tour/named-parameters.md
@@ -6,7 +6,7 @@ disqus: true
tutorial: scala-tour
num: 33
-tutorial-previous: default-parameter-values
+previous-page: default-parameter-values
---
When calling methods and functions, you can use the name of the variables explicitly in the call, like so:
diff --git a/tutorials/tour/nested-functions.md b/tutorials/tour/nested-functions.md
index 3737eeea7f..74066b17b7 100644
--- a/tutorials/tour/nested-functions.md
+++ b/tutorials/tour/nested-functions.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 8
-tutorial-next: currying
-tutorial-previous: higher-order-functions
+next-page: currying
+previous-page: higher-order-functions
---
In Scala it is possible to nest function definitions. The following object provides a `filter` function for extracting values from a list of integers that are below a threshold value:
diff --git a/tutorials/tour/operators.md b/tutorials/tour/operators.md
index 2120960cf1..e95b81e031 100644
--- a/tutorials/tour/operators.md
+++ b/tutorials/tour/operators.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 29
-tutorial-next: automatic-closures
-tutorial-previous: local-type-inference
+next-page: automatic-closures
+previous-page: local-type-inference
---
Any method which takes a single parameter can be used as an *infix operator* in Scala. Here is the definition of class `MyBool` which includes methods `and` and `or`:
diff --git a/tutorials/tour/pattern-matching.md b/tutorials/tour/pattern-matching.md
index 5c8eed9f0a..e86743b922 100644
--- a/tutorials/tour/pattern-matching.md
+++ b/tutorials/tour/pattern-matching.md
@@ -7,8 +7,8 @@ disqus: true
tutorial: scala-tour
num: 11
-tutorial-next: singleton-objects
-tutorial-previous: case-classes
+next-page: singleton-objects
+previous-page: case-classes
---
Scala has a built-in general pattern matching mechanism. It allows to match on any sort of data with a first-match policy.
diff --git a/tutorials/tour/polymorphic-methods.md b/tutorials/tour/polymorphic-methods.md
index 8b707ec1ae..970c8cb40d 100644
--- a/tutorials/tour/polymorphic-methods.md
+++ b/tutorials/tour/polymorphic-methods.md
@@ -7,8 +7,8 @@ disqus: true
tutorial: scala-tour
num: 27
-tutorial-next: local-type-inference
-tutorial-previous: implicit-conversions
+next-page: local-type-inference
+previous-page: implicit-conversions
---
Methods in Scala can be parameterized with both values and types. Like on the class level, value parameters are enclosed in a pair of parentheses, while type parameters are declared within a pair of brackets.
diff --git a/tutorials/tour/regular-expression-patterns.md b/tutorials/tour/regular-expression-patterns.md
index 3e0e2a298a..c52170d64c 100644
--- a/tutorials/tour/regular-expression-patterns.md
+++ b/tutorials/tour/regular-expression-patterns.md
@@ -7,8 +7,8 @@ disqus: true
tutorial: scala-tour
num: 14
-tutorial-next: extractor-objects
-tutorial-previous: xml-processing
+next-page: extractor-objects
+previous-page: xml-processing
---
## Right-ignoring sequence patterns ##
diff --git a/tutorials/tour/sequence-comprehensions.md b/tutorials/tour/sequence-comprehensions.md
index 80002ac3e9..0db09e17c2 100644
--- a/tutorials/tour/sequence-comprehensions.md
+++ b/tutorials/tour/sequence-comprehensions.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 16
-tutorial-next: generic-classes
-tutorial-previous: extractor-objects
+next-page: generic-classes
+previous-page: extractor-objects
---
Scala offers a lightweight notation for expressing *sequence comprehensions*. Comprehensions have the form `for (enumerators) yield e`, where `enumerators` refers to a semicolon-separated list of enumerators. An *enumerator* is either a generator which introduces new variables, or it is a filter. A comprehension evaluates the body `e` for each binding generated by the enumerators and returns a sequence of these values.
diff --git a/tutorials/tour/singleton-objects.md b/tutorials/tour/singleton-objects.md
index ce6120479e..94fae67119 100644
--- a/tutorials/tour/singleton-objects.md
+++ b/tutorials/tour/singleton-objects.md
@@ -7,8 +7,8 @@ disqus: true
tutorial: scala-tour
num: 12
-tutorial-next: xml-processing
-tutorial-previous: pattern-matching
+next-page: xml-processing
+previous-page: pattern-matching
---
Methods and values that aren't associated with individual instances of a [class](classes.html) belong in *singleton objects*, denoted by using the keyword `object` instead of `class`.
diff --git a/tutorials/tour/tour-of-scala.md b/tutorials/tour/tour-of-scala.md
index 01d94c5313..99f69584b3 100644
--- a/tutorials/tour/tour-of-scala.md
+++ b/tutorials/tour/tour-of-scala.md
@@ -7,7 +7,7 @@ disqus: true
tutorial: scala-tour
num: 1
outof: 33
-tutorial-next: unified-types
+next-page: unified-types
---
Scala is a modern multi-paradigm programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages.
diff --git a/tutorials/tour/traits.md b/tutorials/tour/traits.md
index 7b5ad73042..89c4468090 100644
--- a/tutorials/tour/traits.md
+++ b/tutorials/tour/traits.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 4
-tutorial-next: mixin-class-composition
-tutorial-previous: classes
+next-page: mixin-class-composition
+previous-page: classes
---
Similar to interfaces in Java, traits are used to define object types by specifying the signature of the supported methods. Like in Java 8, Scala allows traits to be partially implemented; i.e. it is possible to define default implementations for some methods. In contrast to classes, traits may not have constructor parameters.
diff --git a/tutorials/tour/unified-types.md b/tutorials/tour/unified-types.md
index 5c4bff50a2..223aaceb00 100644
--- a/tutorials/tour/unified-types.md
+++ b/tutorials/tour/unified-types.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 2
-tutorial-next: classes
-tutorial-previous: tour-of-scala
+next-page: classes
+previous-page: tour-of-scala
---
In contrast to Java, all values in Scala are objects (including numerical values and functions). Since Scala is class-based, all values are instances of a class. The diagram below illustrates the class hierarchy.
diff --git a/tutorials/tour/upper-type-bounds.md b/tutorials/tour/upper-type-bounds.md
index b344ede3a0..859f3f0575 100644
--- a/tutorials/tour/upper-type-bounds.md
+++ b/tutorials/tour/upper-type-bounds.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 19
-tutorial-next: lower-type-bounds
-tutorial-previous: variances
+next-page: lower-type-bounds
+previous-page: variances
---
In Scala, [type parameters](generic-classes.html) and [abstract types](abstract-types.html) may be constrained by a type bound. Such type bounds limit the concrete values of the type variables and possibly reveal more information about the members of such types. An _upper type bound_ `T <: A` declares that type variable `T` refers to a subtype of type `A`.
diff --git a/tutorials/tour/variances.md b/tutorials/tour/variances.md
index 73c98c9926..653c5d9643 100644
--- a/tutorials/tour/variances.md
+++ b/tutorials/tour/variances.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 18
-tutorial-next: upper-type-bounds
-tutorial-previous: generic-classes
+next-page: upper-type-bounds
+previous-page: generic-classes
---
Scala supports variance annotations of type parameters of [generic classes](generic-classes.html). In contrast to Java 5 (aka. [JDK 1.5](http://java.sun.com/j2se/1.5/)), variance annotations may be added when a class abstraction is defined, whereas in Java 5, variance annotations are given by clients when a class abstraction is used.
diff --git a/tutorials/tour/xml-processing.md b/tutorials/tour/xml-processing.md
index a16a4359c2..e0b63dbe26 100644
--- a/tutorials/tour/xml-processing.md
+++ b/tutorials/tour/xml-processing.md
@@ -6,8 +6,8 @@ disqus: true
tutorial: scala-tour
num: 13
-tutorial-next: regular-expression-patterns
-tutorial-previous: singleton-objects
+next-page: regular-expression-patterns
+previous-page: singleton-objects
---
Scala can be used to easily create, parse, and process XML documents. XML data can be represented in Scala either by using a generic data representation, or with a data-specific data representation. The latter approach is supported by the *data-binding* tool `schema2src`.