はじめてのにき

_ proto 批判

http://reasonablypolymorphic.com/blog/protos-are-wrong/

proto はもっとよくできる、と直感的に思う、が、この批判は的を射てる部分もあるけど、外してる部分もあるように思う。 wire format への言及が無いけど、わかった上なのかどうかよくわからない。

現状の問題はこうすれば良いよ、と書いてある点については、要するに普通のプログラミング言語に近付けるということであるけど、シリアライズフォーマットというのは当然プログラミング言語と違うわけで、デシリアライズされた構造体をどこまでリッチにしていっても、結局はホスト言語の機能をフルに使う場合はホスト言語で自分で書いたクラスに移し変えるなり、 proto を持ったクラスにサポート情報を保持して使うことになると思う。そうならないシリアライズフォーマットは、 Smalltalk とかそういう世界観だけな気がする

具体的な例としては、参照みたいなのがまず欲しくなってくるものの一つとしてあって、 YAML とかだと参照があったりするけど、それを足したとしても、今度は、検索が線型より速い構造が欲しいとか、なんだかんだでホスト言語側の機能で自動生成されたコードを補うコードを書くことになると思う

で、どうせ補うコードを書くことになるのであれば、シリアライズフォーマットの仕様はリッチすぎず(ところで最初に批判されてる oneof と map はどちらも後づけ syntax sugar みたいなものだという理解)、便利さと速度やフットプリントのトレードオフがあれば、常に速度&フットプリントの方に倒す、というのは理に適っていると思う。 proto の改善できる部分のうち、どの部分は速度&フットプリントを犠牲にせず使えるかは、ぱっとはわからないなあと思う

API (C++ と Python だけについて書いています) について、 proto は読む方の API はまあ普通で、問題はあると思うがかろうじて苦労なく使えるレベルだと思う。新規にデータを作る時の API も、こっちは多少苦労する程度に気持ち悪い API ではあると思うけど、まあ覚えればなんとかなる。

ただ、 proto の編集は批判されている通り、困った問題が起きることが多い。ただ、それはこう、データを編集しなければならないならちゃんとホスト言語の構造体に移しかえて、編集が終わったらデシリアライズしなさい、というだけのことかなあと思う。めんどくさいよーと思うかもしれないけど、

int LoadInt(FILE* fp) {
  int v;
  size_t r = fread(&v, sizeof(v), 1, fp);
  if (r != 1)
    return -1;
  return v;
}
bool LoadString(FILE* fp, string* s) {
  int len = LoadInt(fp);
  if (len < 0)
    return false;
  s->resize(len);
  size_t r = fread(&(*s)[0], 1, s->size(), fp);
  if (r != s->size())
    return false;
  return true;
}

みたいな関数をいちいち作ってやるのに比べればマシだしねぇ…

なんか、 proto 作った時に、アプリケーション固有の proto と対応した boilerplate コードを作りたい時がある気がしていて、そういうのが作りやすいと良い気がするなぁとか思う。直近での対処は proto とアプリケーション固有コードを両方とも生成することで対処したけど、まあこれで十分という感もある

(18:48)