Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed even more typos. #72

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions src/pages/implicits/conversions.md
Original file line number Diff line number Diff line change
Expand Up @@ -82,6 +82,8 @@ object IntImplicits {
def times(func: Int => Unit) =
for(i <- 0 until n) func(i)
}

import scala.language.implicitConversions

implicit def intToIntOps(value: Int) =
new IntOps(value)
Expand Down
2 changes: 1 addition & 1 deletion src/pages/implicits/enrichment.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ class ExtraStringMethods(str: String) {
val vowels = Seq('a', 'e', 'i', 'o', 'u')

def numberOfVowels =
str.toList.filter(vowels contains _).length
str.toLowerCase.toList.filter(vowels contains _).length
}
```

Expand Down
4 changes: 2 additions & 2 deletions src/pages/implicits/implicit-parameters.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ object PersonWriter extends HtmlWriter[Person] {
}
```

This issue with this code is that we need manage a lot of `HtmlWriter` instances when we render any complex data. We have already seen that we can manage this complexity using implicit values and have mentioned *implicit parameters* in passing. In this section we go in depth on implicit parameters.
This issue with this code is that we need to manage a lot of `HtmlWriter` instances when we render any complex data. We have already seen that we can manage this complexity using implicit values when we mentioned about *implicit parameters* in passing. In this section we go in depth on implicit parameters.

### Implicit Parameter Lists

Expand Down Expand Up @@ -108,7 +108,7 @@ object TypeClass {

### Take Home Points

Implicit parameters make type classes more convenient to use. We can make an entire parameter list with the `implicit` keyword to make it an implicit parameter list.
Implicit parameters make type classes more convenient to use. We can make an entire parameter list using the `implicit` keyword. To make it an implicit parameter list we write as

```scala
def method[A](normalParam1: NormalType, ...)(implicit implicitParam1: ImplicitType[A], ...)
Expand Down
4 changes: 2 additions & 2 deletions src/pages/implicits/instances.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,9 +43,9 @@ List(2, 4, 3).sorted
List(1, 7 ,5).sorted
```

Note we didn't supply an ordering to `sorted`. Instead, the compiler provides it for us.
Note that we didn't supply an ordering to `sorted`. Instead, the compiler provided it for us.

We have to tell the compiler which values it is allowed pass to methods for us. We do this by annotating a value with `implicit`, as in the declaration `implicit val ordering = ...`. The method must also indicate that it accepts implicit values. If you look at the [documentation for the `sorted` method on `List`](http://www.scala-lang.org/api/current/index.html#scala.collection.immutable.List) you see that the single parameter is declared `implicit`. We'll talk more about implicit parameter lists in a bit. For now we just need to know that we can get the compiler to supply implicit values to parameters that are themselves marked implicit.
We have to tell the compiler which values it should pass to the methods for us. We do this by annotating the value with an `implicit` modifier, as in the declaration `implicit val ordering = ...`. The method must also indicate that it accepts implicit values. If you look at the [documentation for the `sorted` method on `List`](https://www.scala-lang.org/api/current/scala/collection/immutable/List.html#sorted[B>:A](implicitord:scala.math.Ordering[B]):Repr) you see that the single parameter is declared `implicit`. We'll talk more about implicit parameter lists in a bit. For now we just need to know that we can get the compiler to supply implicit values to parameters that are themselves marked implicit.

### Declaring Implicit Values

Expand Down
8 changes: 4 additions & 4 deletions src/pages/implicits/organising.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
## Organising Type Class Instances

In section we'll learn about the places the compiler searches for type class instances (implicit values), known as the *implicit scope*, and we'll discuss how to organise type class instances to make their use more convenient.
In this section we'll learn about the places the compiler searches for type class instances (implicit values), known as the *implicit scope*, and we'll discuss how to organise type class instances to make their use more convenient.

### Implicit Scope

Expand All @@ -17,7 +17,7 @@ def sorted[B >: A](implicit ord: math.Ordering[B]): List[A]
The compiler will look in the following places for `Ordering` instances:

- the companion object of `Ordering`; and
- the companion object of the type `B` (which is `A` or a supertype).
- the companion object of the type `B` (which is `A`) a supertype of `A`.

The practical upshot is we can define type class instances in the companion object of our types (the type `A` in this example) and they will be found by the compiler without the user having to import them explicitly.

Expand Down Expand Up @@ -103,7 +103,7 @@ This leads us to our first pattern for packaging type class instances.
<div class="callout callout-info">
#### Type Class Instance Packaging: Companion Objects {-}

When defining a type class instance, if
When defining a type class instance, and

1. there is a single instance for the type; and
2. you can edit the code for the type that you are defining the instance for
Expand Down Expand Up @@ -166,7 +166,7 @@ then *define the type class instance in the companion object of the type*. This

### Packaging Implicit Values Without Companion Objects

If there is no good default instance for a type class instance, or if there are several good defaults, we should not place an type class instances in the companion object but instead require the user to explicitly import an instance into the local scope.
If there is no good default instance for a type class instance, or if there are several good defaults, we should not place any type class instances in the companion object but instead require the user to explicitly import an instance into the local scope.

In this case, one simple way to package instances is to place each in its own object that the user can import into the local scope. For instance, we might define orderings for `Rational` as follows:

Expand Down
2 changes: 1 addition & 1 deletion src/pages/implicits/using-type-classes.md
Original file line number Diff line number Diff line change
Expand Up @@ -65,4 +65,4 @@ implicitly[Example]
implicitly[Example] == implicitExample
```

The `implicitly` method takes no parameters but has a generic type parameters. It returns the implicit matching the given type, assuming there is no ambiguity.
The `implicitly` method takes no parameters but has a generic type parameter. It returns the implicit matching the given type, assuming there is no ambiguity.
2 changes: 1 addition & 1 deletion src/pages/pattern-matching/extractors.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ import scala.util.matching.Regex
```

```tut:book
val r = new Regex("""(\d+)\.(\d+)\.(\d+)\.(\d+)""")
val r: Regex = """(\d+)\.(\d+)\.(\d+)\.(\d+)""".r

"192.168.0.1" match {
case r(a, b, c, d) => List(a, b, c, d)
Expand Down