fix typo s/LowPritoryImplicits/LowPriorityImplicits

xuwei-k · xuwei-k · commit 7ac547e7632d · 2015-02-02T18:40:37.000+09:00
diff --git a/ja/overviews/collections/arrays.md b/ja/overviews/collections/arrays.md
@@ -59,7 +59,7 @@ Scala 2.8 の設計はより単純なものだ。ほぼ全てのコンパイラ
     res5: Array[Int] = Array(3, 2, 1)
 
 `intArrayOps` が先の例で暗黙の変換により導入されたものだ。ここで問題となるのが、先の例でコンパイラがどうやってもう一つの暗黙の変換である `WrappedArray` に対して `intArrayOps` を優先させたのかということだ。結局の所、両方の変換も配列をインプットが指定した `reverse` メソッドをサポートする型へ変換するものだ。二つの暗黙の変換には優先順序が付けられているというのがこの問への答だ。`ArrayOps` 変換には、`WrappedArray` 変換よりも高い優先順位が与えられている。`ArrayOps` 変換は `Predef` オブジェクトで定義されているのに対し、`WrappedArray` 変換は
-`Predef` が継承する `scala.LowPritoryImplicits` で定義されている。子クラスや子オブジェクトで定義される暗黙の変換は、親クラスで定義される暗黙の変換に対して優先される。よって、両方の変換が適用可能な場合は、`Predef`
+`Predef` が継承する `scala.LowPriorityImplicits` で定義されている。子クラスや子オブジェクトで定義される暗黙の変換は、親クラスで定義される暗黙の変換に対して優先される。よって、両方の変換が適用可能な場合は、`Predef`
 で定義されるものが選ばれる。文字列まわりにも似た仕組みがある。
 
 これで、配列において列との互換性および全ての列メソッドのサポートを実現しているかが分かったと思う。ジェネリック性についてはどうだろう。Java では型パラメータ `T` に対して `T[]` と書くことはできない。では、Scala の `Array[T]` はどのように実装されるのだろう。`Array[T]` のようなジェネリックな配列は実行時においては、Java の 8つあるプリミティブ型の
diff --git a/overviews/collections/arrays.md b/overviews/collections/arrays.md
@@ -58,7 +58,7 @@ The `ArrayOps` object gets inserted automatically by the implicit conversion. So
     scala> intArrayOps(a1).reverse
     res5: Array[Int] = Array(3, 2, 1)
 
-where `intArrayOps` is the implicit conversion that was inserted previously. This raises the question how the compiler picked `intArrayOps` over the other implicit conversion to `WrappedArray` in the line above. After all, both conversions map an array to a type that supports a reverse method, which is what the input specified. The answer to that question is that the two implicit conversions are prioritized. The `ArrayOps` conversion has a higher priority than the `WrappedArray` conversion. The first is defined in the `Predef` object whereas the second is defined in a class `scala.LowPritoryImplicits`, which is inherited from `Predef`. Implicits in subclasses and subobjects take precedence over implicits in base classes. So if both conversions are applicable, the one in `Predef` is chosen. A very similar scheme works for strings.
+where `intArrayOps` is the implicit conversion that was inserted previously. This raises the question how the compiler picked `intArrayOps` over the other implicit conversion to `WrappedArray` in the line above. After all, both conversions map an array to a type that supports a reverse method, which is what the input specified. The answer to that question is that the two implicit conversions are prioritized. The `ArrayOps` conversion has a higher priority than the `WrappedArray` conversion. The first is defined in the `Predef` object whereas the second is defined in a class `scala.LowPriorityImplicits`, which is inherited from `Predef`. Implicits in subclasses and subobjects take precedence over implicits in base classes. So if both conversions are applicable, the one in `Predef` is chosen. A very similar scheme works for strings.
 
 So now you know how arrays can be compatible with sequences and how they can support all sequence operations. What about genericity? In Java you cannot write a `T[]` where `T` is a type parameter. How then is Scala's `Array[T]` represented? In fact a generic array like `Array[T]` could be at run-time any of Java's eight primitive array types `byte[]`, `short[]`, `char[]`, `int[]`, `long[]`, `float[]`, `double[]`, `boolean[]`, or it could be an array of objects. The only common run-time type encompassing all of these types is `AnyRef` (or, equivalently `java.lang.Object`), so that's the type to which the Scala compiler maps `Array[T]`. At run-time, when an element of an array of type `Array[T]` is accessed or updated there is a sequence of type tests that determine the actual array type, followed by the correct array operation on the Java array. These type tests slow down array operations somewhat. You can expect accesses to generic arrays to be three to four times slower than accesses to primitive or object arrays. This means that if you need maximal performance, you should prefer concrete over generic arrays. Representing the generic array type is not enough, however, There must also be a way to create generic arrays. This is an even harder problem, which requires a little bit of help from you. To illustrate the problem, consider the following attempt to write a generic method that creates an array.
 
