[ruby-dev:36609] Re: {Complex,Rational}::Unify

> 当然, mathnで対応することはできます.
> 
> が, この問題はふなばさんが過去の互換性をなんの同意もなく変更したことに
> あります. 私としては, この変更に対して, 最小限の変更で対応するために交
> 渉してきましたが, 交渉は意味がなかったようです.

それはまったく違います。[ruby-dev:36468] で、まつもとさんも意義を認めて
いますし、[ruby-dev:36483] で石塚さんも意義を認めています。変更を急いだ
のは凍結前だったからで、石塚さんも直すことを宣言しています。

> 私としては, すでに存在するライブラリに対する互換性もなく独断的にAPIを
> 変更した方が絶対的に悪いと考えていますので, rational.c/complex.c を
> mathnが動作する状態に戻すか, そもそも rational.c/complex.c を導入した
> のが早すぎたといえなくもないです. ruby-1.9.1ではさらに遡って, 1.8の
> rational.rb/complex.rbに戻すことを提案します.

悪いとかそういう問題じゃないと思いますね。変更する前に、少し調べたんで
すが、Unify を定義したら振舞いが変更になる、というのは、公式にも非公式
にも文書では語られていないと思います。

僕としては、石塚さんの意志をかなり尊重してきたつもりです。それは、
Complex/Rational の原作者だからですけど。実際のところ石塚さんにすべてお
伺いを立てなければならないと思っていないのですが、今回も、石塚さんの話
を聞いていますね。

元に戻すというのも、申し訳ないですが、rationrl.rb、complex.rb、
mathn.rb の放置ぶり、今回にしても面倒だから、という言い方ですから。僕と
しては、なんなら自分で直してもいいなと思いましたが、石塚さんの mathn は
自分で頑張りたい、という意志を尊重したつもりです。

> さらにいえば, 今回のふなばさんの独断的な変更/対応は全く納得がいきませ
> ん.  拡張ライブラリ添付ライブラリならまだしも組み込みクラスに関する変
> 更に関することなのでことさらです. rational.c/complex.c に関しては, 実
> 際には原コード, 正木コード, その他と複数の実装があるので, もっとまとも
> にメンテナンスできる方(上記の意味で)のコードに変更をすることも含めて検
> 討する必要があると思います.

組み込みだからこそ、mathn の勝手にできないです。今回の石塚さんの主張は
むしろ、Complex/Rational を私物化しているように見えるんですよ。ちょっと
した石塚さんの我儘だと思います。

> この問題に対しては, 当然ふなばさんでは決定できませんので, まつもとさん
> に裁定をお願い致します.

それは勝手にどうぞ。

ただ、既にいったように、ギリギリになって mathn にも影響がでるようになっ
たのは申し分けない、と思っています。言い訳めいていますが、しかしそれも
石塚さんへの配慮、遠慮があったことも影響していると思います。純粋に
Complex/Rational の事を考えれば、もっと早く決断すべきでした。