小飼です。TypeScript
の2系が正式に公開されました。
多数の機能追加・改善がありましたが、中でも目玉の一つはstrictNullChecks
ではないでしょうか。
今まで曖昧だった、『ある型がnull/undefinedを取り得るか?』ということを、型レベルで厳密に検査・検出することができるようになる機能です。
実行時エラーになるバグの多くが、不用意なundefined/nullへのアクセスから生じることからも、これがアプリケーションの堅牢性に大きく寄与する機能であることが伺えます。
JavaScript has two values for “emptiness” – null and undefined. If null is the billion dollar mistake, undefined only doubles our losses. These two values are a huge source of errors in the JavaScript world because users often forget to account for null or undefined being returned from APIs.
例えば従来のTypeScript
では、以下のようなInnerFoo
がnull
を取り得るコードであっても、問題なくコンパイルが通っていました。1
2
3
4
5
6
7
8
9
10
11
12// (旧)実行時エラーになるが、Validなコードだった
interface InnerFoo {
buzz: number;
}
interface OuterFoo {
bar: InnerFoo;
}
const innerFoo = null;
const foo: OuterFoo = { bar: innerFoo };
console.log(foo.bar.buzz); // Uncaught TypeError: Cannot read property 'buzz' of null
strictNullChecks
を有効化していると、InnerFoo
を{ buzz: number } | null
と表現しない限り、const innerFoo = null;
のようにnull
を代入できません。
また、InnerFoo
を{ buzz: number } | null
と表現する限り、foo.bar.buzz
から直接値を取り出すこともできなくなります。
1 | // (新)Foo.barがnullを『持ちうる』という文脈を型として明示しないとコンパイルエラーになるようになった |
これによって、いわゆるMaybeモナド(※)
で包んでおいた方が良さそうな型が検出される、とも捉えられるかと思います。
(ScalaとかSwiftではOption/Optional型として提供されていますね)
せっかくこの機能を適用するのであれば、生の文法通りT | null
と書くよりも、いい機会なのできちんと定義されたMaybeモナド
に包んできれいに使いたいものです。
※ すごく雑に説明すると『ある型の値を持っているかも知れない』型のこと
そこで本稿では、TypeScript
で書かれたMaybeモナド
を提供するライブラリをいくつか見てみて、その使い勝手を検証してみたいと思います。
monapt
Option
, Try
, Future
を提供する、インターフェースがちょっとScala
っぽいライブラリです。
1 | import { equal } from "assert"; |
TsMonad
Maybe
, Either
, Writer
を提供するライブラリで、JavaScriptにおける代数的データ構造の共通仕様を策定しているFantasyLandのインターフェースに準拠しているそうです(この辺かなり理解が怪しいのですが…)
1 | /// <reference path="./node_modules/tsmonad/dist/tsmonad.d.ts" /> |
monadness
この中では一番若いライブラリで、Either
, Option
, Tuples
を提供しています。
インターフェースはmonapt
に似ていますが、唯一パターンマッチ(風)メソッドの実装されていないライブラリでもあります。
まだ開発中のライブラリのようですので、今後実装されていく予定なのかも知れません。
1 | import { equal } from "assert"; |
まとめ
TypeScript
で扱えるMaybeモナド
を提供するライブラリをいくつか紹介してみました。JavaScript
には言語組み込みのパターンマッチが無いだけに、代替となるメソッドを生やしてプロパティ名でパターンマッチ風の動作を実現しているような実装にグッと来ました。
(当然細かいパターンの指定やパターンガードはできないので、Scala
やSwift
のパターンマッチと較べてしまうと機能的にかなり見劣りしてしまうのですが…)
さて、実際に簡単なコードを描いてみてMaybe
のみの使い勝手で言うと、どのライブラリにも大きな差は無いように思います。
この中から選ぶとすると、同時に提供している型に欲しいものがあるか、で選ぶことになるかも知れません。
個人的には、Maybe
モナドに余分な(filterとか)メソッドが生えてて便利そうなのと、インターフェースが最近かじっているScala
に似ていて読みやすいあたりでmonapt
を選びたいと思っています。(Either
が欲しいところですが、Try
がそれに相当する型として提供されているので)
簡単な内容でしたが、今回書いたコードはここにまとめておきました
compare-maybe-monad
以上、参考になればうれしいです。