[ruby-dev:33575] Re: rational, complex and nuby

> ちょっと見たところ、Enumerable#stable_sort_byがsortを使っている
> ので安定でないようです。

うっかりしていました。直しておきます。ありがとうございます。

> Numeric#infinite? 同様、「Floatかどうかというのはあまり関係がな
> い」という気がします。それに、truncateはRationalにも追加されてい
> たりで、floorだけが不要というのはちょっと疑問を感じます。

それはどうですかね。Numeric#floor の実装は、ぜんぜん一般的な解決になっ
てないんですよ。rational では、別途実装すべきです。ruby では、抽象クラ
スで、プロトコルなりインターフェイスを示すということもないので、Float 
でしか意味のないものを Numeric に置いておく必要はないと思います。

floor だけじゃないですよ。truncate、ceil、round も同じです。

むしろ、rational や complex に不用心に継承されるといった害悪のほうが気
になります。利用者が rational をつかっていて、floor をとったら、一旦、
Float を経由して精度を落していた、なんて想像しないでしょう。

> 実装上難しいというよりは、文法の拡張になるので記法のほうが問題で
> すね。あとは必要性と。(#...)では、今まではコメントだったものが有
> 効な式になってしまう点が気になります。また、二次的ですが、エディ
> タが混乱するというのもうれしくない点です。

僕も最初は、別のものを考えていたのですが、変更箇所を見た瞬間に (#...) 
でいいや、ということになってしまいました。決断に5秒とかかっていないの
で、これが最高だというつもりもありません。ただ正直そんなに悪い感じもし
てません。

> ちなみに、私が考えていたのは、@{...}とかです。ライブラリとして必
> 要なものは、1.9では大体準備できているので、そのうち時間が空いた
> ら提案しようかとは思っていました。

文法的なことはともかく、期待しています。

> RationalやComplexの組込みは、リテラルも含めてまぁいいんじゃない
> かと思うのですが、mathnはどうでしょうねぇ。少なくとも、//演算子
> にはいささか抵抗を感じます。たとえば string.split // などという
> ものがsyntax errorになってしまうこととか。

まあ、簡単に ruby に採用されないようだがら、こういうものを作ってみたわ
けですけど、実際には、たいした影響はないように感じています。// 自体は、
Smalltalk や Python にもあるので、新奇なものでもないですし。

文法上の課題としては、括弧のあつかいのほうがデカいので、むしろ、引数の
括弧省略を止めてもいいと思います。

とりあえず、rational と complex の組みこみ (未だあまりちゃんと組みこめ
てないけど)、リテラルの導入あたりは今回の主眼だったので、そこが「まぁ
いいんじゃないか」なら、十分でしょう。