Conflict Merge

typescript-kr · Junhong-Kim · Apr 10, 2018 · Apr 10, 2018 · Apr 10, 2018 · Apr 10, 2018
commit f4905c6f3a194aaed67ae85c4975b1af11e76f5d
diff --git a/.gitignore b/.gitignore
@@ -1,7 +1,5 @@
 _book
 .DS_Store
-<<<<<<< HEAD
-.idea/vcs.xml
 
 # Created by https://www.gitignore.io/api/node,macos,windows,intellij,sublimetext,visualstudiocode
 
@@ -228,8 +226,4 @@ $RECYCLE.BIN/
 # Windows shortcuts
 *.lnk
 
-# End of https://www.gitignore.io/api/node,macos,windows,intellij,sublimetext,visualstudiocode
-=======
-.idea
-node_modules
->>>>>>> master
+# End of https://www.gitignore.io/api/node,macos,windows,intellij,sublimetext,visualstudiocode
diff --git a/pages/Declaration Merging.md b/pages/Declaration Merging.md
@@ -1,10 +1,6 @@
 # 소개
 
-<<<<<<< HEAD
-TypeScript의 고유한 개념 중 일부는 타입 수준에서 JavaScript 객체의 형태를 설명합니다.  
-=======
 TypeScript의 고유한 개념 중 일부는 타입 레벨에서 JavaScript 객체의 형태를 설명합니다.  
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 특히 TypeScript에서의 고유한 예로는 '선언 병합'이라는 개념이 있습니다.  
 이 개념을 이해하는 것은 기존 JavaScript를 사용할 때 이점을 제공할 것입니다.   
 또한 고급 추상화 개념에 대한 문을 열어줍니다.
@@ -15,47 +11,27 @@ TypeScript의 고유한 개념 중 일부는 타입 레벨에서 JavaScript 객
 
 # 기본 개념 (Basic Concepts)
 
-<<<<<<< HEAD
 TypeScript에서 선언은 다음 세 가지 중 하나 이상의 엔티티를 생성합니다: 네임스페이스, 타입 또는 값  
 네임스페이스-생성 선언은 점 표기법을 사용하여 접근하는 이름이 포함된 네임스페이스를 생성합니다.  
 타입-생성 선언은 다음과 같습니다: 선언된 형태로 표시되고 주어진 이름에 바인딩 되는 타입을 작성합니다.  
-=======
-TypeScript에서 선언은 다음 세 가지중 중 하나 이상의 엔티티를 생성합니다: 네임스페이스, 타입 또는 값  
-네임스페이스-생성 선언은 점 표기법을 사용하여 접근하는 이름이 포함된 네임스페이스를 생성합니다.  
-타입-생성 선언은 다음과 같습니다: 선언된 형태로 표시되고 주어진 이름에 바인딩되는 타입을 작성합니다.  
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 마지막으로, 값-생성 선언은 출력된 JavaScript에서 볼 수 있는 값을 만듭니다.
 
 |   선언 타입   | 네임스페이스 | 타입 |  값  |
 |---------------|:------------:|:----:|:----:|
-<<<<<<< HEAD
 | 네임스페이스  |     X        |      |   X  |
 | 클래스        |              |   X  |   X  |
 | 열거형        |              |   X  |   X  |
 | 인터페이스    |              |   X  |      |
 | 타입 별칭     |              |   X  |      |
 | 함수          |              |      |   X  |
 | 변수          |              |      |   X  |
-=======
-| Namespace     |     X        |      |   X  |
-| Class         |              |   X  |   X  |
-| Enum          |              |   X  |   X  |
-| Interface     |              |   X  |      |
-| Type Alias    |              |   X  |      |
-| Function      |              |      |   X  |
-| Variable      |              |      |   X  |
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 
 각 선언으로 생성된 내용을 이해하면 선언 병합을 수행할 때 병합되는 내용을 이해하는 데 도움이 됩니다.
 
 # 인터페이스 병합 (Merging Interfaces)
 
 가장 단순하고 아마도 가장 일반적인 타입의 선언 병합은 인터페이스 병합입니다.  
-<<<<<<< HEAD
 가장 기본적인 수준에서 이 병합은 두 선언의 멤버를 기계적으로 같은 이름의 단일 인터페이스에 결합합니다.
-=======
-가장 기본적인 수준에서 이 병합은 두 선언의 멤버를 기계적으로 같은 이름의 단일 인터페이스에 결합시킵니다.
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 
 ```ts
 interface Box {
@@ -70,21 +46,12 @@ interface Box {
 let box: Box = {height: 5, width: 6, scale: 10};
 ```
 
-<<<<<<< HEAD
 인터페이스의 비-함수 멤버는 고유해야 합니다.  
 고유하지 않다면 같은 타입이어야 합니다.  
 컴파일러는 인터페이스가 모두 같은 이름이지만 다른 타입의 비-함수 멤버를 선언하는 경우 오류를 발생시킵니다.
 
 함수 멤버의 경우 같은 이름의 각 함수 멤버가 같은 함수의 오버로드를 설명하는 것으로 간주합니다.  
 또한 후위의 인터페이스 `A`와 인터페이스 `A`를 병합하는 경우에는 두 번째 인터페이스가 첫 번째 인터페이스보다 우선순위가 더 높다는 점이 주목됩니다.
-=======
-인터페이스의 비-함수 멤버는 고유해야합니다.  
-고유하지 않다면 동일한 타입이어야합니다.  
-컴파일러는 인터페이스가 모두 같은 이름이지만 다른 타입의 비-함수 멤버를 선언하는 경우 오류를 발생시킵니다.
-
-함수 멤버의 경우 동일한 이름의 각 함수 멤버가 동일한 함수의 오버로드를 설명하는 것으로 간주됩니다.  
-또한 후위의 인터페이스 `A`와 인터페이스 `A`를 병합하는 경우에는 두번째 인터페이스가 첫번째 인터페이스보다 우선 순위가 더 높다는 점이 주목됩니다.
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 
 예를 들어 다음과 같습니다:
 
@@ -114,11 +81,7 @@ interface Cloner {
 }
 ```
 
-<<<<<<< HEAD
 각 그룹의 요소는 같은 순서를 유지하지만 그룹 자체는 나중에 오버로드가 발생한 것이 가장 먼저 병합됩니다.
-=======
-각 그룹의 요소는 동일한 순서를 유지하지만 그룹 자체는 나중에 오버로드가 발생된 것이 가장 먼저 병합됩니다.
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 
 이 규칙에 대한 한가지 예외는 특수한 서명(specialized signatures)입니다.  
 서명의 타입이 *단일* 문자열 리터럴 타입(예 : 문자열 리터럴의 유니온이 아닌)인 매개 변수가 있는 경우 병합된 오버로드 목록의 맨 위로 버블링됩니다.

diff --git a/pages/Functions.md b/pages/Functions.md
@@ -85,11 +85,7 @@ let myAdd: (baseValue: number, increment: number) => number =
 
 ## 타입 추론 (Inferring the types)
 
-<<<<<<< HEAD
 예를 들어 TypeScript 컴파일러는 한쪽에는 타입이 있지만 다른 한쪽에 타입이 없는 경우 그 타입을 이해할 수 없다는 것을 알게 됩니다:
-=======
-예를 들면 TypeScript 컴파일러는 한쪽에는 타입이 있지만 다른 한쪽에 타입이 없는 경우 그 타입을 이해할 수 없다는 것을 알게 됩니다:
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 
 ```ts
 // myAdd는 완벽하게 함수 타입을 가지고 있습니다.
@@ -484,4 +480,4 @@ alert("card: " + pickedCard2.card + " of " + pickedCard2.suit);
 
 `function pickCard (x) : any` 조각은 오버로드 목록의 일부가 아니므로 두 개의 오버로드만 있습니다:  
 하나는 객체를 취하고 하나는 숫자를 취합니다.  
-`pickCard`를 다른 매개 변수 타입과 함께 호출하면 오류가 발생합니다.
+`pickCard`를 다른 매개 변수 타입과 함께 호출하면 오류가 발생합니다.
diff --git a/pages/Generics.md b/pages/Generics.md
@@ -89,11 +89,7 @@ function loggingIdentity<T>(arg: T[]): T[] {
 }
 ```
 
-<<<<<<< HEAD
 `loggingIdentity` 는 타입 매개 변수 `T` 를 인수로 받고 `arg` 는 `T` 배열이며 `T` 배열을 반환합니다. 숫자 배열을 인수로 넘기면 `T` 가 `number` 에 바인딩 되기 때문에 숫자 배열을 반환할 것입니다. 이렇게하면 모든 타입이 아닌 처리하고자 하는 타입의 일부로 제네릭 타입 변수 `T` 를 사용하여 유연성을 높일 수 있습니다.
-=======
-`loggingIdentity` 는 타입 매개 변수 `T` 를 인자로 받고 `arg` 는 `T` 배열이며 `T` 배열을 반환합니다. 숫자 배열을 인자로 넘기면 `T` 가 `number` 에 바인딩 되기 때문에 숫자 배열을 반환할 것입니다. 이렇게하면 모든 타입이 아닌 처리하고자 하는 타입의 일부로 제네릭 타입 변수 `T` 를 사용하여 유연성을 높일 수 있습니다.
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 
 혹은 다음 예제와 같이 작성할 수 있습니다.
 

diff --git a/pages/Module Resolution.md b/pages/Module Resolution.md
@@ -61,11 +61,7 @@ relative import는 import된 파일과 관련하여 해석됩니다.
 
 그러나 non-relative 모듈 imports의 경우 컴파일러는 imports 파일이 포함된 디렉토리부터 시작하여 일치하는 정의 파일을 가져오기 위해 디렉토리 트리를 찾으려합니다.
 
-<<<<<<< HEAD
 예를 들어:
-=======
-예를 들면:
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 
 
 `moduleB`를 소스 파일에서 `import { b } from "moduleB"`와 같이 상대적으로 가져오지 않으면 `"moduleB"`를 찾기 위해 다음과 같은 위치에서 찾게 됩니다:

diff --git a/pages/Modules.md b/pages/Modules.md
@@ -335,11 +335,7 @@ export var t = something + 1;
 Node.js는 `--module commonjs`를 사용하세요.  
 require.js의 경우 --module amd를 사용합니다.  
 
-<<<<<<< HEAD
 예를 들어:
-=======
-예를 들면:
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 
 ```Shell
 tsc --module commonjs Test.ts
@@ -482,11 +478,7 @@ Node.js에서 대부분의 작업은 하나 이상의 모듈을 로드하여 수
 각 모듈을 `.d.ts` 파일에 최상위 수준의 내보내기 선언으로 정의할 수 있지만 더 넓은 `.d.ts` 파일로 작성하는 것이 더 편리합니다.  
 그렇게하기 위해서 ambient 네임스페이스와 비슷한 구조를 사용하지만 나중에 import 할 수 있는 모듈의 `module` 키워드와 따옴표 붙은 이름을 사용합니다.
 
-<<<<<<< HEAD
 예를 들어:
-=======
-예를 들면:
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 
 ##### node.d.ts (simplified excerpt)
 
@@ -566,11 +558,7 @@ console.log(data, fileContent);
 이러한 모듈을 [UMD](https://github.com/umdjs/umd) 모듈이라고 합니다.  
 이러한 라이브러리는 import 또는 글로벌 변수를 통해 접근할 수 있습니다.
 
-<<<<<<< HEAD
 예를 들어:
-=======
-예를 들면:
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 
 ##### math-lib.d.ts
 
@@ -614,11 +602,7 @@ export 클래스의 정적 메서드에도 비슷한 문제가 있습니다 -
 모듈의 주요 목적이 하나의 특정 export를 저장하는 것이라면 이를 default export로 export 하는 것을 고려해야 합니다.  
 이렇게 하면 importing를 사용하며 실제로 import를 더 쉽게 사용할 수 있습니다.
 
-<<<<<<< HEAD
 예를 들어:
-=======
-예를 들면:
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 
 #### MyClass.ts
 

diff --git a/pages/Namespaces.md b/pages/Namespaces.md
@@ -195,11 +195,7 @@ tsc --outFile sample.js Validation.ts LettersOnlyValidator.ts ZipCodeValidator.t
 또는 파일별 컴파일(기본값)을 사용하여 각 입력 파일에 대한 JavaScript 파일을 하나씩 내보낼 수 있습니다.  
 만약 여러 개의 JS 파일이 생성되면 웹 페이지에 있는 `<script>`태그를 사용하여 출력된 각 파일을 적절한 순서대로 로드해야 합니다.
 
-<<<<<<< HEAD
 예를 들어:
-=======
-예를 들면:
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
 
 ##### MyTestPage.html (excerpt)
 

diff --git a/progress.md b/progress.md
@@ -23,21 +23,12 @@
 - [x] 네임스페이스
 - [x] 네임스페이스와 모듈
 - [x] 모듈 해석
-<<<<<<< HEAD
 - [X] 선언 병합
 - [X] JSX
-- [X] Decorators
-- [X] Mixins
-- [x] Triple-Slash Directives
-- [x] Type Checking JavaScript Files
-=======
-- [ ] 선언 병합
-- [ ] JSX
-- [ ] Decorators
-- [ ] Mixins
-- [ ] Triple-Slash Directives
-- [ ] Type Checking JavaScript Files
->>>>>>> 764cb472fb0987a1c9354cebc6699cc41293004c
+- [X] 데코레이터
+- [X] 믹스인
+- [x] 트리플-슬래시 지시자
+- [x] JavaScript 파일 타입 검사
 ## Declaration Files
 - [ ] Introduction
 - [ ] Library Structures