diff --git a/src/pages/implicits/conversions.md b/src/pages/implicits/conversions.md index 163c845..90f88b9 100644 --- a/src/pages/implicits/conversions.md +++ b/src/pages/implicits/conversions.md @@ -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) diff --git a/src/pages/implicits/enrichment.md b/src/pages/implicits/enrichment.md index 1b545d1..c824e8c 100644 --- a/src/pages/implicits/enrichment.md +++ b/src/pages/implicits/enrichment.md @@ -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 } ``` diff --git a/src/pages/implicits/implicit-parameters.md b/src/pages/implicits/implicit-parameters.md index bdba1a8..72fe3fe 100644 --- a/src/pages/implicits/implicit-parameters.md +++ b/src/pages/implicits/implicit-parameters.md @@ -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 @@ -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], ...) diff --git a/src/pages/implicits/instances.md b/src/pages/implicits/instances.md index 24c3e7a..0f5b61f 100644 --- a/src/pages/implicits/instances.md +++ b/src/pages/implicits/instances.md @@ -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 diff --git a/src/pages/implicits/organising.md b/src/pages/implicits/organising.md index 4938834..e7db99d 100644 --- a/src/pages/implicits/organising.md +++ b/src/pages/implicits/organising.md @@ -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 @@ -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. @@ -103,7 +103,7 @@ This leads us to our first pattern for packaging type class instances.
#### 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 @@ -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: diff --git a/src/pages/implicits/using-type-classes.md b/src/pages/implicits/using-type-classes.md index 2f56eda..318224a 100644 --- a/src/pages/implicits/using-type-classes.md +++ b/src/pages/implicits/using-type-classes.md @@ -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. diff --git a/src/pages/pattern-matching/extractors.md b/src/pages/pattern-matching/extractors.md index 40a3ff2..b5dbe4d 100644 --- a/src/pages/pattern-matching/extractors.md +++ b/src/pages/pattern-matching/extractors.md @@ -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)