読者です 読者をやめる 読者になる 読者になる

テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(msgpack-nim report) Nimオブジェクトから/への変換について

Msgpackの公式に名前を載せるのは, GithubレポジトリのDescriptionにヒントを書いておくと, クローラがそれを拾って自動生成するというものだった. これがウェブ業界の考え方か. 私には思いもつかなかった. 私は, msgpackの運営にメールしなければいけないのかと思い, 躊躇していた.

f:id:akiradeveloper529:20150302204447p:plain

Nimのオブジェクト(整数とか文字列とか)をMsgオブジェクト(PFixNumとかFixStrとか)に変換するレイヤを作るとして, 悩みは, 可逆性だ.

つまり, Nim -> Msg -> Nimと変換した時に, 最初と最後が同値かどうか. この性質が失われるとテストがめんどくさくなる. 例えば, [0, 64]という配列はどうするか?これはFixArray [PFixNum, Uint8]とするのが良さそうだ. これを復元しよう. [uint8]となるのが妥当だろうか?しかし, 仮に元の配列の型が[int64]だったらどうするのだろうか?どうやってもInt64に復元する方法は, Nimにはないと思う(Haskellならあると思う).

なので, 制約をつける. Nimオブジェクトでは常にintしか使わないでくださいとする. すると上記のケースについてはクリアされる. ここまで考えてか慣習からかはわからないが, この割り切りをしている実装はある. 例えばHaskell版. 動的型付け言語では, この悩みは一切ないだろうから, 本当に素敵だねって思う.

仮にintしか使わない制約を導入したとする. しかしそれでも, Nimオブジェクトにはまだ制約がかかる. それは, [1, "a"]のような配列が定義出来ないことだ. Msgpackでは配列がヘテロであり, その理由は構造体を模写するためという. この機能が失われるのは, 結構痛い.

この問題に対して私は, Msg型のオブジェクトについてはidでmapするということを考えている. つまり, そのままMsgオブジェクトとして透過させる. 結果として, Nimオブジェクトの層は, NimオブジェクトとMsgオブジェクトの混合となる. この発想は悪くないし拡張性がいい. 仮にmsgpackの仕様が今後拡張されて, なおNimオブジェクトで表現することが難しくなっても, Msgオブジェクトで表現することで逃げられるからである. 逃げ道のある設計は良いことが多い.

(追記)

少し考えて誤りに気づいた. MsgオブジェクトからNimオブジェクトに戻す時, 動作としては「変換しない」ことを期待するが, それを判定するのは不可能だ. つまり, ヘテロな配列はサポートが不可能である.