2017年9月18日から20日まで、広島国際会議場にて「RubyKaigi 2017」が開催されました。2日目の基調講演は、Rubyの作者である、まつもとゆきひろさんです。
「よく天才プログラマーと紹介されるが、自分では自分のことを才能ある言語デザイナーだと思っている。なぜなら、自分は他の言語をいろいろ研究し、良いと思った機能をたくさん取り入れてきたからだ」というつかみで始まったまつもとさんの講演は、module
のいろいろな側面を例にとり、Rubyがどのようにデザインされてきたかを紹介しました。
オブジェクト指向
Rubyのオブジェクト指向はSmalltalk、Lispを通してSimulaの考えを受け継いだものだと、まつもとさんは言います。Simulaは最初のオブジェクト指向言語と言われており、クラス・オブジェクト・継承などの、現代のオブジェクト指向では基本といえる機能を一通り備えています。
しかし、Simulaは継承の方法としてスーパークラスを一つだけ持てる単一継承しかサポートしておらず、複数の側面からオブジェクトを表現できなかったため、Lispでスーパークラスを複数持てる多重継承が発明されました。多重継承によりオブジェクトを柔軟に表現できるようになりましたが、その一方で多重継承では継承関係がとても複雑になってしまうという問題が発生しました。C3 linearization algorithm(ネットワーク状になっている上位クラスの優先順位をつけるアルゴリズム)が登場しましたが、それでも人が使ったときにわかりやすいとは限りません。
そこで、FlavorsというLisp方言から多重継承の機能を一部制限した形でFlavor(Mixin)が発明されます。Flavorはアイスクリームのフレーバーをイメージしており、フレーバー単体でアイスが作れないようにFlavor単体ではインスタンスが作れません。Flavorをオブジェクトに混ぜ合わせることで振る舞いを追加できます。Rubyはmodule
という形でFlavorを受け継いでいます。
moduleの様々な側面
Ruby開発当初の用途
こういった経緯から、Rubyにおけるmodule
は当初Mixinのための機能として実装されました。そこから、関連するクラスやモジュールをモジュールの中に詰め込むネームスペースとして使われるようになり、またシングルトンとしても使われるようになります。機能の集まりとしてmodule
を使うようにもなりました。Mathモジュールがその代表例です。
Ruby 2.0 からの用途
さらにRuby 2.0から、メソッド結合の単位としての機能が追加されます。
その当時主にRuby on Railsで使われていたalias_method_chain
と呼ばれるテクニックがありました。これはalias_method
を使ってメソッドを置き換えるテクニックですが、無計画に使うとプログラムを派手に壊す問題がありました。
そこでRailsコミュニティから、より使いやすいメソッド結合の単位としてModule#prepend
が提案されます。これが採用され、静的で失敗しにくいメソッドの置き換えができるようになりました。Module#prepend
によってCLOS(CommonLisp Object System)のaround hookと同じように、あるメソッドの前後をフックして処理を行えるようになりました。これは以前注目されていた「アスペクト指向プログラミング」に近い振る舞いになります。
module
にはさらにRefinementの単位としての機能があります。Rubyはオープンクラスによって既に存在しているクラスにメソッドを追加したり置き換えたりできます。これらはモンキーパッチと呼ばれていますが、グローバルにクラスの振る舞いを変更してしまうとありとあらゆるところに影響を及ぼす可能性があるため、なるべく変更を一つの箇所にとどめたほうが予期しないバグを埋め込まずに済みます。このスコープを絞ってモンキーパッチングできるのがRefinementです。usingを使って必要なところでだけメソッドを置き換えることができます。
今後の想定
そして、現在提案段階の新たなmodule
の機能であるStructual Signatureについて、まつもとさんから説明がありました。これは、構造型をモジュールを使って検査することができる機能です。必要なメソッドをモジュールにまとめておき、検査したいオブジェクトに対してconform
を呼ぶことによってそのメソッドすべてが使えるかをチェックできるそうです。
Rubyの今後
このようにRubyはさまざまな言語やコミュニティから影響を受けデザインされています。そしてこれからもこのようにデザインされていきます。今のRubyは完璧な言語ではなく、対処しなければならないたくさんの問題があります。Ruby3x3に掲げているPerformance
, Concurrency
, StaticAnalysis
などは、解決されるにはまだ道半ばです。RubyKaigi 2017でもこれらについての発表があります。
Rubyの開発を始めた頃はまつもとさんが1人で開発を行っていましたが、今ではまつもとさんが「リードデザイナー」としてRubyのあるべき姿やゴールを示し、コミュニティ全体でそれに向かって開発を進めていく、というスタイルが成立しています。
「Ruby3x3のように私んが声をあげたらコミュニティの人たちがそれに答えようと頑張ってくれる。こうあるべきというゴールを示してコミュニティの人たちが直してくれる。今やRubyは“私”の言語ではなく、“私たち”の言語になった」とまつもとさんは語りました。
最後に、「Rubyより良い言語が出てきたらRubyをその言語と同じくらい良くしよう。そして、世界をより良くしよう」と締めくくりました。