sealedの存在意義.scala

/*
 「sealedの存在意義」とされている理由

 1. パターンマッチでの被覆性(網羅性)を保証したい
 2. ML はコンパイラで検出できる
 3. Scala ではできない (型推論が弱い、と言われる理由もここ？)
 4. sealed をつけると検出できるようにした
*/

// 例 # via http://d.hatena.ne.jp/kmizushima/20091229/1262091617

// クラス定義
trait Exp
case class Add(l: Exp, r: Exp) extends Exp
case class Num(v: Int) extends Exp

// マッチング利用
def eval(e: Exp): Int = e match {
  case Add(l, r) => eval(l) + eval(r)
  //case Num(...)が抜けてる!
}

// これが通常スルーされるが、"sealed trait Exp" にしておけば、警告される

/*
疑問点

 1. sealed をつければ検出できるのであれば、コンパイラの能力的には推論可能？(-> [存在意義3]と矛盾?)
 2. (1を敷衍して) sealed がなくても、同一ファイルの定義ではあるというテイでコンパイルすればよくね？
 3. 実装者のミスを防ぐ仕組みなのに、sealedをつける行為はミスしない、という前提がある
    # sealedのつけ忘れに関しては結局被覆性を保証できてない
 4. (3を敷衍して) デフォルトが sealed で、継承許可時に unsealed する仕様にすべき
    # 超絶不便で誰得だが、[存在意義1]の観点からはそうでないと話がおかしい
 5. 被覆性の確保ために拡張性を放棄している
    # どんなに自信があってももちろん自己責任でいい、という状況でもExpを継承した拡張が定義できない
*/


/*
理解
 1. Scalaの型推論が強化されるまでの暫定処置 (ML並になればなくなる(不要になる)と想像)
 2. sealed を付け忘れると結局意味がないので、付いてれば保証されるけど、全体的な安全性は保証しない
 3. [クラス定義者]と[マッチング利用者]が別の場合には意味がある
    # 前者がライブラリ提供者などで、後者を信じてなくて、class,trait定義に付けておく場合
    # (-> それでもやはり拡張性が犠牲になる問題は残る)
*/