Option型

nullをかかないために使う、と断言されてね。

def exists():Boolean

という関数を持ったクラスXがあった。

このクラスの変数xを持つクラスがあって、

def exists():Boolean = {
  x.exists()
}

となっていたところ、実はこのクラスの実態が存在しない場合、exists()=falseのインスタンスが返ってくるのではなく、nullが返ってくるという仕様だったことが発覚した。

修正せざるを得ず、自分は素直に

def exists():Boolean = {
    x != null && x.exists()
}

としたのだが、数学科出身のScala厨が「ひいぃぃぃっ！　nullがっ。nullがぁぁぁぁっ！！」

ってんで、

def exists():Boolean = {
    Option(x).exists(_.exists())
}

と書き直したという。

これがscalaらしい、と。

上の例は、scalaの書籍で見たことがないし、javaっぽいから不可だと。

Optionでくるんで、とやったらxがnullである可能性が読めないだろ？　といったところ、

「scalaではヌルポをなくすためにOption型を使わなければならないんです」

と。

いや、既にxはnullで汚染されてるし、この関数から外にはnullは漏れないし、これでなぜぬるぽが問題になるのか。Option型を「使わなければならない」んじゃなく、「使うことができる」のだ。

この場合のような、コントロール下にあるnullはぬるぽの原因にはならない。

といったのだが、理解してもらえなかったようだ。

さらに、あるBoolean(b)の値で呼び出し関数が変わるという部分について、

if(b){
    trueFunc()
}else{
    falseFunc()
}

としていたところ、「if文ってjavaっぽいので、match文に書き換えてください」という不可解なレビューがつき、

b match {
    case true => trueFunc()
    case false => falseFunc()
}

って……。

まぁ、なんていうか、形式主義的すぎというか、正直、アホなんではないかと呆れた。

あと、シングルスレッドのバッチ処理で、「メインスレッドをブロックするような書き方は如何なものか」って物言いがついたり。

バッチでメインスレッドって……。

もう、ね。

こりゃScala厨は嫌われるわ、と思った。

ちなみに、nullだって立派な値だ。

null==Noneではない。

Some(null)という、nullという処理すべき値が存在する、という意味をもった実体を作ることができるからね。

Mapなどのチェインの中に使う場合に、nullの場合は後続の処理をしない、っていうならOption型のNoneを返せばいいだけの話だよ。

熱脳しゃちょのブログ