option-tにPromiseへのキャストメソッドを用意したりなど

ECMAScript javascript

自作RustスタイルECMAScript用Option型ライブラリoption-tをいろいろアップデートしたので、リリースノートがてら書く。ご存知ない方はこちらをどうぞ。要はOption<T>/Maybe型だ。

Promiseへのキャストメソッドを用意した

ECMA 262の文化には、すでにMaybeもどきの標準仕様が存在する。ご存知Promiseだ。

だが、Promiseは非同期前提の操作になるので、同期的に実行するAPI群との親和性が良いとは言えず、かといって全てをPromiseにするほどでもない場合のために、わざわざこんなライブラリを作ったというのは前に書いた通り。

でも、今の世の中、どこかしらの関数がPromiseを返すじゃん？そこに上手く混ぜられるととっても楽じゃん？　てなわけでcast用メソッドとしてOptionT.asPromise()を追加した。これにより、スムーズにPromiseと混ぜることができ、非常に最高な気分になれる。

こんな感じ。XHRを投げつつ、別のフラグの有無を確認し、両方が成功した場合に〜みたいなケースに有用になりました。

var option = new OptionT.Some();
var xhr = new Promise();

Promise.all([
  option.asPromise(),
  xhr,
]).then((tuple)=>{
  var responce = tuple[1];
  ...
});

ちなみに、Promise<T> -> Option<T>の変換は、非同期から同期への変換なんで無理ですやってない。

いろいろメソッドを追加した

追加しました。前よりも楽に書けるようになったと思います、どんなの使えるかはgithubのissue一覧かCHANGELOG.mdをみてください。

ここで注意点がひとつ. Option<T>.mapOr()とOption<T>.mapOrElse()については、unstable APIという区分にしてある。理由は、取りうる仮引数の順序が、「デフォルト値生成」 -> 「map関数」の順序になっているため、直感に反するのではないかというのが理由。元のRustのstd::optionのAPIが微妙っちゃ微妙なので、Rustの動向を無視してもいいのだが、ちょうど今のタイミングで、Rust側でも似たようなissueが立っていて、できることならもう少し様子見したいというところ。なのでunstableという区分にはしている。

まあ、変更するとしても仮引数の順序を入れ替えるだけで、挙動としては変わらないのと、そういう破壊的変更するときはsemver的にメジャーバージョン上げるので、使うのをためらうほどではないかもしれない。ただし、今の所はNODE_ENV = 'production'時以外は``console.warn()でうるさく警告出してるので気をつけて下さい。

一応フィードバックありましたらお知らせください。