Matzにっき

_ [Ruby]アジャイルな言語デザイン

Module#instance_methodsなどは引数が省略された場合、 あるいは引数として偽を指定した場合にはそのクラスで定義されているメソッドのリストを、 真を指定した場合にはスーパークラスまでさかのぼってメソッドのリストを返します。

しかし、Rubyのような言語にとって継承は単なる実装の共有が目的ですから、 興味があるのは「そのクラスのインスタンスが持っているメソッドのリスト」のはずです。 ということは、現在のデフォルトは間違っていることになります。 またやっちゃった。

そこでさっそく修正しました。

ところが直後に、この修正によってirbが動かなくなったとDave Thomasから報告がありました。 具体的にはdelegate.rbがこの変更に対応していなかったせいです。 この問題そのものはdelegate.rbを修正することで簡単に直せたのですが、 この一件で大きな矛盾が明らかになったような気がします。

つまり、言語またはライブラリのデザインに間違い(使いにくさ、一貫性のなさ)があったとき、 長期的な観点からは修正した方が良いに決まっています。 間違い、一貫性のなさは言語の良さを損ねます。 しかし、その修正の結果、非互換が生まれれば、少なくとも短期的には多くの問題が生じます。 ユーザが多ければ多いほどその問題は深刻になります。

かつて、Rubyのユーザがわずかであった頃にはこれはあまり問題ではありませんでした。 しかし、いやまRubyユーザは世界中に数えきれないほどいます。 ささいな変更でも影響がばかにできなくなっています。

短期的な視点に立って欠点を放置するか、長期的な視点に立って欠点を修正するか。

アジャイルな立場からいえば、変化を恐れず対応するべきなのでしょうが、言語の場合には

• インタフェースが大規模かつ複雑
• その直接の利用者がプログラム
• ユーザがとてつもなく多い

という点で、急激に変化してはいけない傾向があります。 アジャイルの指導者の一人であるDave Thomasに相談しましたが、 彼にも良いアイディアはないようです。

結局今回の問題は、

• 2004年1月まで変更は先送り
• その間はwarningを出す

という方向で結論を出しましたが、変化に強い言語デザインとはどのようなものかということについては 結論が出ないままなのです。