Skip to content

equality.md 완료 (#24) #25

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

Merged
merged 1 commit into from
Jul 11, 2013
Merged
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
8 changes: 4 additions & 4 deletions ko/overviews/collections/equality.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
layout: overview-large
title: Equality
title: 동일성

disqus: true

Expand All @@ -9,9 +9,9 @@ num: 13
language: ko
---

The collection libraries have a uniform approach to equality and hashing. The idea is, first, to divide collections into sets, maps, and sequences. Collections in different categories are always unequal. For instance, `Set(1, 2, 3)` is unequal to `List(1, 2, 3)` even though they contain the same elements. On the other hand, within the same category, collections are equal if and only if they have the same elements (for sequences: the same elements in the same order). For example, `List(1, 2, 3) == Vector(1, 2, 3)`, and `HashSet(1, 2) == TreeSet(2, 1)`.
스칼라 컬렉션 라이브러리는 동일성 판단과 해싱에 있어 일괄적인 방법을 사용한다. 먼저, 컬렉션을 집합(set), 맵(map)과 열(sequence)로 나누어 종류가 다를 경우 언제나 다른 것으로 본다. 예를 들어 `Set(1, 2, 3)``List(1, 2, 3)`은 같은 요소를 갖지만 서로 다르다. 종류가 같은 컬렉션끼리는 요소가 일치하는 경우에만 같은 것으로 본다. (열의 경우 순서 또한 동일해야 한다). 예를 들어 `List(1, 2, 3) == Vector(1, 2, 3)``HashSet(1, 2) == TreeSet(2, 1)`은 참이다.

It does not matter for the equality check whether a collection is mutable or immutable. For a mutable collection one simply considers its current elements at the time the equality test is performed. This means that a mutable collection might be equal to different collections at different times, depending what elements are added or removed. This is a potential trap when using a mutable collection as a key in a hashmap. Example:
동일성 판단에 있어 해당 컬렉션의 변경 가능 여부는 중요하지 않다. 변경 가능한 컬렉션에서는 단순히 동일성 판단 시점의 요소만을 고려한다. 이는 한 컬렉션이 요소의 추가 또는 제거에 따라 서로 다른 시각에 각기 다른 컬렉션과 동일할 수도 있음을 의미한다. 변경 가능한 컬렉션을 해시맵의 키로 사용할 경우 다음과 같은 문제가 생길 수 있다:

scala> import collection.mutable.{HashMap, ArrayBuffer}
import collection.mutable.{HashMap, ArrayBuffer}
Expand All @@ -28,4 +28,4 @@ It does not matter for the equality check whether a collection is mutable or imm
java.util.NoSuchElementException: key not found:
ArrayBuffer(2, 2, 3)

In this example, the selection in the last line will most likely fail because the hash-code of the array `xs` has changed in the second-to-last line. Therefore, the hash-code-based lookup will look at a different place than the one where `xs` was stored.
이 예제에서 마지막 줄의 선택은 이전 줄에서 배열 `xs`의 해시 코드가 달라짐에 따라 십중팔구 실패하게 된다. 즉, 해시 코드 기반 탐색시 `xs`가 저장된 시점과는 다른 위치를 참조하게 되는 것이다.