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 을 가지고 실습&고민 해보자
    • top, pop, push
    • http://www.scala-lang.org/node/129

• private 생성자 다루기

  • javap를 이용해 다음이 생성하는 바이트 코드를 확인해보자.( -private 확인)
  1. class Queue[T] (val leading:List[T], val trailing:List[T]) 2. class Queue[T] (private val leading:List[T], private val trailing:List[T]) 3. 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
    • 저장 공간이라 생각하면 covariant가 맞지만 setter의 인자는 contravariant position
    • 예, Verified 객체(진행 예제 참고)

• variance position 결정하는 메커니즘

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

• ETC

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

• Scala의 교훈

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