2016年09月16日
_ GObject Introspection
RubyKaigi 2016ですとうさんがGObject Introspection (以下GIと省略)について講演していたので、すとうさんから聞いた話や私が考えたことなどをまとめます。
GI は何のために作られたか。GI はどのような仕組みなのか。
JavaScript や Python から Gtk や Gnome 関連のライブラリを使うため。
そのため、（ある程度）言語非依存なフレームワークにするため、「C library <-(a)-> GI <-(b)-> 各言語(JS,Python,Ruby,etc)」という仕組みになっていて、(a)だけ用意すると(b)の部分はGIのフレームワークが面倒を見てくれる、という仕組みになっている。
Ruby から使うためにはどうすればよいか。拡張ライブラリとの違いは？
拡張のライブラリの場合「C library <-> Ruby」の「<->」の部分を Ruby-C API を用いて C で書いてコンパイルする。
GI の場合は「C library <-(a)-> GI <-(b)-> Ruby」という構造になっていて、 (a)の部分を GI の API を用いて C で書いてコンパイルする。 (b)はRuby GIライブラリが面倒を見てくれる。実はここで書いたCのコードの 関数のシネグチャやコメントなどからも必要な情報を読みだす。
GCは？
GObject 自体がリファレンスカウントを持っているので、これを使う。
利点は？
- 上の話の (b) から先の部分の言語を変更することができる。JavaScriptやPythonであれば問題なく動作すると考えらえる。SWIGも同じようなことはできるはずだが、間接層が薄くて実際問題としてあまりうまくいかない。GIはかなりリッチな間接層なのでそれなりにうまくいく。
- 上の利点と深く関連したことだが、PythonやJavaScript、PHPの人々と協力して開発を進めることが容易
欠点は？
- FFIのように「Cコンパイラを使わずに開発する」ようなことはできない。特にWindowsで開発環境を整えるのはかなり面倒
- Ruby-C API の代わりに GI の API を用いることになるので、Ruby だけを考えるならとくに開発が楽になるわけではない
- Ruby-C API を使うよりは柔軟性が欠ける
結論
上に書いた利点が重要かどうか、が鍵。
この仕組みが一番役立つのは、「C libraryの提供者が各言語用のバインディングを用意したい」場合であろう。例えば「libgit2 (git の機能を提供するC library）の開発者側がスクリプト言語用のバインディングを用意したい」というときには有用であると考えられる。Ruby以外の言語に興味がない人にはそれほど利点はないかもしれない（他の言語を使う人と協力できるならそうでもないかも）。