19장 type parameterization

nephilim edited this page Apr 1, 2012 · 1 revision
Clone this wiki locally

19장 정리

  • fully persistent data structure

    • fully persistent = being able to save its history
    • 히스토리 관리가 가능한, immutable한 자료 구조
    • 데이터 변경 시 매번 새로운 객체를 반환하는 형태
  • Queue 작성

    • Q의 경우에는 자료의 추가가 끝에서 이루어짐(append) 반면, 리스트는 앞에서(prepend)
    • 자료 저장 순서
      1. ascending: enqueue가 time-proportional 하지 않음
      2. descending: head, tail이 time-proportional 하지 않음
    • Stack 을 가지고 실습&고민 해보자
  • private 생성자 다루기

    • javap를 이용해 다음이 생성하는 바이트 코드를 확인해보자.( -private 확인)
    • class QueueT
      1. class QueueT
      2. class Queue[T] private ( val leading:List[T], val trailing:List[T])
    • 접근 제어는 trait를 이용해 보다 급진적(?)으로 대응 가능
  • variance annotations

    • generic과 parameterized type의 차이
      • generic은 변수, parameterized type은 값
    • functional world에서는 covariant인 경우가 주이지만, mutable data를 다루게되면 상황이 복잡해짐
    • ex: 자바에서는 배열을 covariant로 취급함
    • 대표적인 예
      1. OutputChannel 참고
      2. Collection과 같은 컨테이너 객체의 setter
      3. 저장 공간이라 생각하면 covariant가 맞지만 setter의 인자는 contravariant position
      4. 예, Verified 객체(진행 예제 참고)
  • variance position 결정하는 메커니즘

    • 다음으로 도출된 position에 모든 타입인자의 position이 맞는지 검증
      1. 최상위는 +로 시작
      2. 메서드 인자: 뒤집기
      3. 메서드 타입 인자: 뒤집기
      4. 타입 인자: A[T]에서 T의 type annotation이 +면 그대로, -면 뒤집기
      5. private[this]는 예외 (목록 19.10)
  • ETC

    • class Covariant[+B]에 대해 다음이 가능
      • class Sub[+A] extends Covariant[A]
      • class Sub[A] extends Covariant[A]
  • Scala의 교훈

    • 타입은 프로그래머를 위해(라고는 하지만 최적화를 위해) 탄생한 규약이며 질서를 부여하는 행위가 의례 그렇듯 현상을 더욱 복잡하게 만들 수 있다. 따라서 타입에 대한 설계 없이 타입을 부여하는 행위 자체에 위험이 내포되어 있다. 타입을 도입하는 순간 골치아픈 세상이 열릴 수도 있다는 말이다.