斎藤です。うーん、うーん。

# 期限切れなら以下、無視してくださって結構です > まつもとさん

色々考えたのですが正直、BigDecimalが現状のまま1.8.0の標準添付として
リリースされてしまう事に、違和感を感じます。

まつもとさんの発言、

----- Original Message ----- 
From: "Yukihiro Matsumoto" <matz / ruby-lang.org>
Sent: Wednesday, July 30, 2003 2:25 AM
Subject: [ruby-dev:21009] Re: [BigDecimal] conflict between Numeric#div and
BigDecimal#div

> というか、もしかしてNumericである必然性は薄かったりします?

の通り、標準添付の数クラスとするには、BigDecimalは少し独自性が
強過ぎはしないか、と思うのです。

1.8.0のリリース時にはいったん削除して、Numericとの関係など、
もう少し洗いなおしてから1.8.1以降に標準添付するのでも、
遅くはないのではないでしょうか。

これは、BigDecimalが実用に耐えない、という話では決してありません。
今の時点でも十分に、使えるライブラリだと思います。
しかし、自分が今まで指摘してきたとおり、既存のNumeric以下のクラス
との親和性については、決して高いとは言えないと思います。

標準添付でない拡張ライブラリにも、有用なものはたくさんあります。
しかしもしライブラリが標準添付になるならば、既存のライブラリとの
親和性・整合性を最重視するべきと思うのです。BigDecimalの存在に
よって、それらに影響が出てしまうのを一番危惧しています。


一時削除を提案する理由としては、今まで取り上げさせて
もらったもの以外にも、

・BigDecimal::double_figは、本当に公開する必要があるのか
 (Float::DBL_FIGで十分な気がする)。

・BigDecimal::BASEは、本当に公開する必要があるのか
 (少なくともBignumではそうしていない)。

・その他BigDecimalにあってFloatにないメソッドは、本当に
 必要なのか(fix,frac,sign)。

・to_s(n)の引数指定は、他のクラスのto_sから類推できる意味を
 変えてしまう事になるのでは(他のto_sでは書式指定をしない)。
 特にInteger#to_s(base)との相性が悪そう。

・to_sの結果がFloatと違う(最初の桁が必ず0である変則的な"%e")
 必要性があるのか。

・inspectの結果が他のNumericクラスと違いすぎるのでは。

・やはりd.sqrt(n)という書き方は従来の慣習にそぐわないのでは。

・splitメソッドのアプローチ自体(ユーザに内部の情報をすべて
 渡すからユーザ側でうまくやって欲しい)が、非OO的ではないか。

・BigDecimal.limitやBigDecimal.modeの指定方法があまりRuby的
 ではない気がする(BigDeciaml.limit=等のほうが自然では)。

・そもそも上記のようなメソッドを使って、ライブラリ全体で
 一つの状態を保持する設計方針は、スレッドを気軽に使える
 Rubyにおいて望ましいのかどうか(少なくともJavaのには無さそう)。

・それ以上に、RationalやComplexがRubyで書かれているのに
 BigDecimalだけCである必要性がどの程度あるのか。
 (以前石塚さんが[ruby-dev:20618]でおっしゃっていたとおり、
 他の実装という選択肢もあり得ますよね)

という点があります。

もちろん、小林さんとしては反論ができる部分が多いにあるとは
思うのですが、総体として、BigDecimalが他のNumericなクラスと
比べて「なじめていない」印象を持つのは、自分だけでしょうか。

もし現状のBigDecimalを標準添付として推す、積極的な意見が
あまり出ないのであれば、急いで1.8.0と一緒にリリースする必要は
ないのでは、という意見でした。

# 繰り返しになりますが、もう時間的に無理という事なら
# それで結構です。 > まつもとさん

--
斎藤ただし