Twitter から
この辺のやりとり勉強になるぅ https://t.co/BQzNAjSoyP
— 松本 亮介 / まつもとりー (@matsumotory) March 18, 2014
というやりとりは，こちら．
@yukihiro_matz ええ，それはRuby世界からの見方ですね．C世界から見れば，const char * の長さが mrb_int になるのは危険です．SIZE_MAX と MRB_INT_MAX の大小関係は，C言語処理系に依りますから．(続
— もなか (@monamour555) March 18, 2014
連ツイなので，前後も読んで頂ければと．
ちなみに，この後，Matz 氏がコミットを一部撤回し，結局のところ，API の分裂は避けられた．
やっちゃマズい fork
ソフトウェア開発の世界では，やってよい fork と，やっちゃマズい fork というのがある． やりかけておいてナンだが，API の fork は，やっちゃマズい系の最右翼だ．
オトナの事情で分裂したオープンソースプロジェクトは，枚挙に暇がない． OpenOffice.org と LibreOffice，Hudson と Jenkins，などなど． そんな事態に陥っても，せめて API は互換になるよう頑張る．
なぜなら，APIの分裂は，開発者の利便性を下げる． 利便性の悪いソフトは，開発者コミュニティから敬遠される． 結局のところ，分裂したプロジェクトの両方にとって損となる．
これは，どんなソフトウェアでも言える話ではある． が，特にオープンソースの世界では，深刻な話となる． 開発者を惹きつけないと，旨味が出ないから．
なんでそんな損な fork を?
じゃあなんで，私が損な選択を敢えてしようとしたのか．
Matz氏がAPIを変えたいと思った理由にも，妥当性はある (上記tweetを読めば，解る人には解る)． そして，私の言い分にも，もちろん妥当性はある．
mrubyリポジトリ上の話題としては過ぎたことなので，どうでもよいといえばどうでもよいのだけれども． C言語の入門を脱したくらいのプログラマが，再利用性の高いライブラリを作ろうと思った時に，有用かもしれないと思った． なので，140字の行間を，私なりに(一方的に)埋めてみる．
今日は，話のマクラだけ．