«前の日記(2003-05-02) 最新 次の日記(2003-05-04)» 編集

Matzにっき


2003-05-03 憲法記念日 [長年日記]

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

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

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

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

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

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

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

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

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

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

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

結局今回の問題は、

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

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

本日のツッコミ(全5件) [ツッコミを入れる]
_ なひ (2003-05-05 11:32)

次の正式リリースまでは変更を我慢する(つまりCVS上では気にせず変更する)でよいとなひは思います。未リリースの1.8は気にせずやってしまえば。。。と。<br>「急激に変化してはいけない傾向」対策としては、変更管理をちゃんとやって、参照しやすくするとか。

_ matz (2003-05-05 12:12)

1.7で追加したものはそれで良いと思いますが、問題は1.6以前と非互換な変更をどうするかということですね。

_ なひ (2003-05-05 12:25)

1.8に限らず、過去と非互換な機能についてもどんどん変更してしまってよいと、なひは思います。1.6.8(1.8.1)で動いてたものが、テストなしに1.6.9(1.8.2)で動くと期待するほうが悪い(となひは思っている)。

_ akr (2003-05-05 14:23)

ソースが分散している世界でリファクタリングが可能か、という話ですかねぇ。<br><br>Smalltalk や Java には機械的なリファクタリングツールが存在するようですから、<br>そういうので、(制限は出るにせよ)ソースが分散してても動くようにしたものが必要なんですかね。<br><br>まぁ、ブロックみたいに難しいのは無理っぽいですが、<br>Object#methods みたいなデフォルト値の変更程度ならなんとかなりそうな気もしないでもないですな。<br><br>そういうのができれば、cvs のマージみたいな操作をすると、<br>依存している処理系やライブラリの(リファクタリングによる)更新にともなって、<br>使用している側も変わるとか。<br><br>まぁ、妄想(というか研究ネタ)ですが。

_ ksr (2003-05-12 11:35)

NETのクラスファイルのバージョン管理はこういう問題に対する一定の回答だと思います。富豪的です:-)。

お名前:
E-mail:
コメント:
[]

«前の日記(2003-05-02) 最新 次の日記(2003-05-04)» 編集

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.