07-robust-with-types-flexible-with-polymorphism

타입으로 견고하게 다형성으로 유연하게

📝 목차

• 1장. 타입 검사 훑어보기
• 2장. 서브 타입에 의한 다형성
• 3장. 매개변수에 의한 다형성
• 4장. 두 다형성의 만남
• 5장. 오버로딩에 의한 다형성
• 💬 느낀점

---

1장. 타입 검사 훑어보기

p3. 타입은 프로그램에 존재하는 값(value)들을 그 능력에 따라 분류한 것이다. 🌵

• 튜브: 어떤 타입을 가진 값은 그 타입에게 기대하는 일을 한다.

p8. 아무리 기술이 발전하고 대단한 천재가 나와도 이런 타입 검사기를 절대 만들 수 없다는 사실이 논리적으로 이미 증명되어 있다. 이는 무려 1930년대에 컴퓨터의 아버지 튜링이 직접 증명한 사실이다. 🐧

• 펭귄: 저자가 쓴 ‘타입 체계' 글 , 정지 문제 증명

p26. 타입 검사기가 a ? b : c를 검사할 때는 a의 계산 결과를 전혀 고려하지 않는다. a가 아무리 간단한 부품이더라도 말이다. '계산 결과를 절대 알아내려 하지 않는다'는 타입 검사의 원칙은 다른 모든 부품에도 똑같이 적용된다. 🌵🍋

• 샐리 : 툴에서 해주던 부분이라 당연하다고 생각하여 한번도 생각해보지 않았던 부분이다. 타입만 확인하면 된다는 생각을 왜 못했을까?

p47. 타입 표시는 '절대로 낡지 않는 주석'인 셈이다. 🌵🍋

• 튜브: 주석은 코드를 이해하는 데 도움을 주는데, 코드 실행과 관련 없다 보니 코드와 매칭되지 않을 수 있다. 타입 표시는 실행 단계에서 걸러지니 코드를 설명해 주면서도 낡을 수가 없다.
• 샐리: 주석은 누군가가 틀렸다고 알려주지 않지만, 타입표시를 해두면 타입이 틀렸다고 알려주기 때문에 훨씬 좋다고 생각한다. 대규모의 프로젝트에서 동적언어를 쓴다면 더욱더 타입 표시가 필요한 것 같다.

p50. 타입 추론은 생략된 타입 표시를 복구할 뿐이다. 타입 표시를 생략하는 거지, 타입 검사를 생략하는 게 아니다. 즉, 타입 검사 중에 생략된 매개변수 타입에 해당하는 타입을 찾을 수 있어야 한다. 🐧🍋

• 펭귄: 동적 언어가 타입이 없는게 아니라 실행하기 직전에 타입을 추론해서 타입을 넣어준다는 것. 이걸 처음 깨달았다.

p55. 앞에서 타입은 '프로그램에 존재하는 값들을 그 능력에 따라 분류한 것'이라 했다... 그러므로 어떤 언어에서는 타입 오류라 볼 수 없었던 버그가 다른 언어에서는 타입 오류가 되는 것이다. 🍋

• 샐리: 리터럴이 그 능력에 따라 분류된 것이라는 말이 충격적이었다. 실제세계에서 문자는 문자로, 숫자는 숫자로 표현하기 때문에 리터럴 간의 차이가 생겨난 것이 아니고, 어떠한 역할에 의해 분류되었다는 것이 신기했다.

p57. 결과적으로 타입이라는 개념의 유연함은 언어 설계자와 개발자에게 여러 선택지를 제공한다. 값을 분류하는 방법에 따라 어떤 오류가 타입 오류가 될 수도 있고 그렇지 않을 수도 있다. 언어 설계자가 개발자의 자유에 가치를 둔다면 값을 대강 분류하도록 타입 검사기를 만들 것이다. ... 반대로 언어 설계자가 더 많은 버그를 찾는 데 가치를 둔다면 값을 더 세밀하게 분류한다. 🐧

• 펭귄: 예전에는 “이 언어는 타입이 없네? 이 언어는 타입이 하나 더 있네?”라고 생각했다면, 이 문장을 읽고 나니 “이 언어는 타입을 이렇게 분류했네?”라고 생각이 바뀌었다.

p57. 미국의 수학자 커리(Haskell Curry)와 논리학자 하워드(William Alvin Howard)가 밝혀낸 사실에 따르면 프로그램에 관한 임의의 성질을 타입으로 표현할 수 있다. 🌵

p62. 다형성(polymorphism)은 타입 검사기의 오판을 줄이는 안전한 기능의 대부분을 차지하는 개념이다. 🌵

• 튜브: 앞으로 잘 알아보자!

^{⬆️ 위로 이동}

2장. 서브 타입에 의한 다형성

p78. 이름에 의한 서브타입을 사용하는 경우, 타입 검사기는 타입이 보여 주는 클래스와 이름과 클래스 사이의 상속 관계만 고려한다. 🐧

p84. 구조에 의한 서브타입을 사용하는 경우, 타입 검사기는 클래스 사이의 상호 관계 대신 클래스의 구조, 즉 각 클래스에 어떤 필드와 메서드가 있는지 고려한다. 클래스 A가 클래스 B에 정의된 필드와 메서드를 모두 정의한다면 A는 B의 서브타입이다. 🐧

• 펭귄: 이름에 의한 서브타입과 구조에 의한 서브타입 각각에 대한 예시입니다. (파이썬이 주언어라 파이썬으로 씁니다. 절대 돌아가지 않아요…)

  #  Person과 Student는 HasEmail의 서브타입
  # 이름에 의한 서브타입
  class HasEmail:
    email: str
  
  class Person(HasEmail):
    name: str
    age: int
  
  class Student(HasEmail):
    name: str
    grade: int
  
  # 구조에 의한 서브타입
  class HasEmail:
    email: str
  
  class Person:
    name: str
    age: int
    email: str
  
  class Student(Email):
    name: str
    grade: int
    email: str

• 튜브: TypeScript에서 사용하는 구조에 의한 서브타입 예시

  interface ExampleProps {
    id: string;
    other: number;
  }
  
  const component = ({ id: String }: ExampleProps) => {};

p88. 다른 코드는 하나도 건드리지 않고 매개변수 타입표시를 { String email; }로 고치기만 해서 모든 문제를 해결한 것이다. 🍋

p97. 단지 sendNewYearEmail이 타입 검사를 통과할 수 있도록 특정 객체가 sendEmail 메서드를 가진다는 사실을 표현하기 위해 만든 타입일 뿐이다. 🍋

• 샐리: abstract에 대한 저자의 해석이 드러나는 부분인 것 같다.

p97. 추상 클래스를 만드는 목적은 언제나 메서드의 존재에 관한 정보를 타입 검사기에 제공하려는 것이다. 그 자체로 객체를 만들려는 게 아니다. 🐧

• 펭귄: 필수적으로 구현해야 하는 요구사항의 관점에서만 생각해봤는데 타입검사기의 관점에서 보니 또 새롭다.

p97. 언어가 구조에 의한 서브타입을 제공한다면 추상 메서드의 필요성이 다소 줄어든다. 🌵

p106. 최대 타입은 모든 타입의 슈퍼타입이다. 🌵🐧

• 펭귄: TypeScript를 쓰면 항상 Any의 유혹을 받게 된다.
• 펭귄: 찾아보다 알게 된 놀라운 사실. TypeScript는 최대 타입으로 Any와 Unknown(나중에 추가됨)이 있는데, 가장 큰 차이는 Any는 타입 검사 자체를 하지 않기 때문에 런타임 때 에러가 발생하고 Unknown을 쓰면 컴파일 시 에러가 발생한다. 즉, Any는 TypeScript를 Python처럼 쓴다는 말이어서 제대로된 타입 검증을 하고 싶다면 Unknown을 써야한다.

p109. 예외로 인한 종료는 타입 오류로 분류하지 않는다. 다시 말해 타입 검사를 통과한 프로그램이더라도 예외가 발생해 실행이 갑작스럽게 중단될 수 있다. 🐧

p114. Void는 함수가 계산을 끝낼 때 아무 값도 반환하지 않는다는 사실을 나타내지만, 최소 타입은 함수가 계산을 끝마치지 못한다는 사실을 나타낸다. 🍋🐧

• 샐리: 계산을 끝마치지 않는다면 아무 타입이나 써도 되는거 아닐까? 이런걸 만들 생각을 했다는게 신기했다.

p115. 최소 타입은 '계산을 끝마치지 못한다'를 표현하니 계산이 끝날 일도 없고 상자가 열릴 일도 없다. 이는 최소 타입에 속하는 값이 존재하지 않는다는 사실과도 일맥상통한다. 🌵

p121. 그래서 이거나 타입을 제공하는 언어는 위치에 민감한 타입 검사라는 정교한 방식의 타입 검사를 사용한다. 변수의 값을 읽는 부품의 타입을 검사할 때 해당 변수가 정의된 곳의 타입 표시만 보는 것이 아니라, 그 변수가 어디서 사용되는지도 고려하는 것이다. 🍋

p123. 위치에 민감한 타입 검사가 잘 작동하도록 프로그램의 구조를 단순하게 만들어야 한다는 것이다. 🍋🐧

• 펭귄: 1장에서 타입 검사기가 통과할 수 있도록 코드를 수정하면서 한다는 말이 기억났다.
• 튜브: 무언가를 설명하려 했는데...

  (a: int | str) => a + 1 : int

p129. 이면서 타입은 다중 상속이 있을 때 유용하다. 다중 상속은 한 클래스가 여러 클래스를 직접 상속하는 것을 말한다. 🌵🍋

• 튜브: 무언가를 설명하려 했는데...

  type A = {a, b, c}, type B = {b, c, d}, type C = A & B -> {b, c}
  type A = {a, b}, type B = A & {c} -> {a, b, c}, type C = A & {d} -> {a,b,d}
  

p140. 결과 타입의 서브 타입 관계가 유지된다는 사실은 나름 직관적인 것에 비해, 매개변수 타입의 서브타입 관계가 뒤집힌다는 사실은 처음 봤을 때 다소 이상하게 들릴 수 있다. 🐧🍋

• 튜브, 샐리, 펭귄: 관련된 내용을 간단히 정리해보자면,
  • 전제: Student가 Person의 서브타입이다.
    1. Student -> Boolean인 경우: Student만 인자로 가능 👉 부모
    2. Person -> Boolean인 경우: Student, Person 모두 인자로 가능 👉 자식
  • 결론: b.는 a.의 서브타입이다. 👉 서브타입 관계가 역전됨

^{⬆️ 위로 이동}

3장. 매개변수에 의한 다형성

p157. 이렇게 choose처럼 한 개 이상의 타입 매개변수를 가지는 함수를 제네릭 함수(generic function)라고 부른다. 🐧

p159. T가 타입 매개변수일 때 함수 안에서 T 타입의 부품은 아무 특별한 능력도 요구되지 않는 곳에만 사용될 수 있다. 🐧🍋🌵

p167. 그러니 타입 인자 추론이 언제나 내가 원하는 대로 되지는 않는다는 사실을 항상 기억해야 한다. 타입 검사기가 내 프로그램을 거부한 이유를 잘 모르겠을 때는 생략한 타입 인자를 하나씩 다시 넣어 보는 것이 도움이 될 수 있다. 🐧🌵

p171. 개발자는 이런 영리한 타입 추론이 어떻게 가능한지 자세히 몰라도 된다. 그저 타입 추론이 주는 해택을 누리면 그만이다. 🐧

• 펭귄: ‘ChatGPT를 사용할 때 ChatGPT가 내부적으로 어떻게 돌아가는지 알지 못해도 사용할 수 있듯이 ChatGPT가 주는 해택을 누리면 그만이다.’라는 느낌..?

p171. 어떤 매개변수가 함수 안에서 특별한 능력이 요구되지 않는 곳에서만 사용된다면 그 매개변수의 타입은 타입 매개변수를 사용해 표현할 수 있다. 따라서 그런 매개변수가 하나라도 발견된다면 그 함수는 제네릭 함수가 된다. 🍋

p172. 하지만 어떤 함수가 자동으로 제네릭 함수가 되었다는 사실을 개발자가 눈치채지 못한다면 문제가 생긴다. 특히 타입 검사기가 내뱉는 오류 메시지를 이해하기 매우 어려워진다.9 🐧

• 펭귄: 특별한 이유가 있지 않는 이상 자동 추론을 쓰진 않을 것 같고 명시적으로 타입을 명시할 것 같다. 나는 알아도 몇 년 후 이 코드를 볼 개발자는 오류를 보고 힘들어 할 수도..?

p173. 따라서 힌들리-밀너 타입 추론을 제공하는 언어를 사용할 때는 우선 매개변수 타입 표시 없이 코드를 작성하다가 이해하기 어려운 오류 메시지가 나오면 함수에 매개변수 타입 표시를 추가해보는 게 좋다.. 🍋

p176. 프로그래밍을 하는 데 꼭 필요한 기본적인 타입조차도 제네릭 타입으로 표현될 정도로 제네릭 타입은 유용하다. 🌵

p181. 리스트의 경우와 마찬가지로 모든 맵의타입을 뭉뚱그려 Map이라고 하는 것은 좋은 선택이 아니다. 그랬다가는 각 맵에 저장된 열쇠와 연결된 값들의 타입이 무엇인지 타입 검사기가 알 수 없게 된다. 🐧

• 펭귄: 문득 든 생각이 파이썬은 동적 언어라 타입 체계가 없지만 타입 힌팅은 가능한데, list와 list[Any]로 타이핑할 때 어떤 차이가 있을까 찾아보았다. 결론은 검사 항목이 하나 더 추가된 느낌이다.

  # python 3.9+
  from typing import Any
  
  my_list: list = [1, 2, 3] # 타입 검사기: "assign된게 list인가?"
  my_list: list[Any] = [1, 2, 3] # 타입 검사기: "assign된게 list인가?", "그 안에 요소가 Any 타입인가?"
  my_list: list[int] = [1, 2, 3] # 타입 검사기: "assign된게 list인가?", "그 안에 요소가 int 타입인가?"

p196. 하지만 이건 우리가 원하는 게 아니다. 우리가 원하는 것은 List<Int> => Int 타입으로도 사용될 수 있고 List<String> => String 타입으로도 사용될 수 있는 함수를 인자로 받는 것이다. 이는 분명히 위의 코드와는 다르다. 🐧

p212. 라이브러리 사용자가 다음처럼 cmp를 사용하도록 강제되는 것이다. 🍋

p212. 반면 무엇인가 타입의 역할은 정반대다. 오히려 타입 검사를 통과할 수 있는 프로그램이 타입 검사를 통과하지 못하도록 방해한다. 이는 보통 필요 없는 능력이다. 하지만 어떤 경우에는 이 능력이 중요하다. 예에서 본 것처럼 라이브러리를 만드는 상황이 여기에 속한다. 🐧🍋

^{⬆️ 위로 이동}

4장. 두 다형성의 만남

p0. 수수수수퍼노바 🐧🍋🌵

• 펭귄: 노바 캔 스탑 하이퍼 스텔라~

^{⬆️ 위로 이동}

5장. 오버로딩에 의한 다형성

p0. 수수수수퍼노바 🐧🍋🌵

• 펭귄: 노바 캔 스탑 하이퍼 스텔라~

^{⬆️ 위로 이동}

---

💬 느낀점

팀원	느낀점
펭귄
샐리
튜브

^{⬆️ 위로 이동}