Kotlin

2月7日金曜日、晴れ

今日は二週間に一度の検証向けリリース日。バグ修正もほぼ終わっているのでざっと動作確認してリリース用チケットを更新し、 OK ですと宣言した。

しかし。リーダーがざっと触ってクラッシュバグを発見。

処理するオブジェクトの数によらずプログレスバーを表示するように施した変更があって(僕がレビューした)、そこが問題だった。サーバー側で用意してくれているサンプルデータでは必ず1件、初期データが入っていること。そして今までは100件を超えたときにはじめてプログレスバーを出していたので気がつかなかったのだけれど、リーダーが0件のデータセットを用意して食わせたことで発覚。
ゼロ割という恥ずかしいバグを出してしまったのだ……。

あまりの恥ずかしさに5分で修正パッチを書いたのだけれど、リーダーは優しく「急がなくていい。検証向けリリースノートに制限事項として書いておいて」、と。

* * *

Kotlin というプログラミング言語がある。

不思議なことに、これが作りだすプログラムは Java 言語のオブジェクトだったり、あるいは JavaScript のソースコードになったりする。(各種 OS やプラットフォームが直接実行できるネイティブ形式の出力もサポートしている)

ソースコードを書いてコンパイルすると、それが他の言語に置き換わるというのはカッコウの托卵っぽくもあり面白かっこいい、気がする。(C 言語だってアセンブリ言語への翻訳器なのだから、ことさら珍しいと騒ぎ立てることではないかも。なお macOS 上の gcc のように LLVM に翻訳する C 言語処理系もある)

* * *

Java にしても JavaScript にしても、なにかの拍子に null という空っぽのオブジェクトを参照してしまうことがある。その時に発生するのが悪名高い null pointer exception というものだ。「ヌルポ」という単語でご存知の方もいらっしゃるだろう。 OS により、プログラムは強制的に終了される。

これまた C 言語に遡る。C 言語では関数の生存期間を超えて存在するオブジェクトを表現するために、必要なメモリー領域を確保して利用する。このメモリー領域の先頭アドレスをポインターという変数で指して関数から戻したり、渡したりする。
ところでメモリーとは無限に切り出せるものでないため、ある時点から確保できなくなる。そんなときに確保できなかったということを示すために使うゼロの値。これが null だ。

あるいはオブジェクトが「ない」ことを示すためのマークとして使ったり、使い終えた領域を解放して、それまで指していたアドレスを保存していたポインター変数をリセットするために使ったりもする。

もとい。
null はオブジェクトがないことを示す値で、(ポインター変数をなくして明示的にメモリーアドレスを指せないようにした) Java にも JavaScript にもこの null の思想は引き継がれている。

悪いことに言語構文上、オブジェクトを指す箇所はすべて null になりうる。どういうことかというと、プログラムが異常停止しないよう予防するためには至るところに if (object != null) { ... } というチェックを入れる必要がある、ということだ。(これを嫌った Java 開発者は、 annotation という機能を利用して @NotNull や @Nullable という修飾語を付して null の可能性を明示することを始めた。しかし強制力はないため、この修飾がないコードが圧倒的多数である)

長かった。ここまで長くなってしまった。

Kotlin は言語規約でこの null 可能性を排除した。その可能性を明示しなければオブジェクトを格納する変数は null を保持できないのだ。基本的に null が存在しないため、コードは圧倒的にコンパクトになる。また null になりうる変数は明示されているためコンパイラーが自動チェック可能で、 null チェックを忘れている箇所がエラーになる。

* * *

や。
null の扱いが素敵なことは Kotlin の大きな特徴なんだけれど。

Version 3.3 になり、正式に言語仕様となった coroutine の話だとか、 REPL の話だとかを書こうとおもっていたのだけれど。
長くなったので別の機会に譲る。


この記事が気に入ったらサポートをしてみませんか?