豊福@パパイヤです。

去年の precision の一連の話は読み流していた
程度だったんでポイントを外した話になったら
ごめんなさい。

ごとけんさん
> また単に演算できればよいというわけではないので変換という点
> では prec は coerce より基本的なのだと考えています。
> もし num が prec を受け付けるなら、
> 
> def coerce(num)
>   if num.type == self.type
>     [num, self]
>   else
>     [num.prec(type), self]
>   end
> end
> 
> とは書けますが、逆に coerce で prec は書けませんし、
> 目指しているモノも違いますよね。

  1 + Complex(2.2, 3.3) に上の coerce を使うと

  if (Complex == Integer) は成り立たないので
else の方の [Complex(2.2, 3.3).prec(Integer), 1]
になってこのときの足算は 1 + Complex(2, 3) となり
間違った答になりませんか。

  私(だけ?)が考えているのは coerce とは自前では
処理し切れない一引数の(多引数でもいいのかもしれ
ないけどとりあえず一引数ということで)メソッド
すべてで使われるもので prec も一引数の自前では処理
し切れないメソッドなので coerce を使う必要がある。
「prec の話と coerce の話は似たところがある」と
いうのはそれが原因ではないかと思っています。

  prec を現在の coerce を使って書けないというのは、
coerce の引数にメソッドの情報がないせいじゃないで
しょうか。
(だいぶ前に新coerce についてのスレッドで関連した話
が出たような気がするんですが自分でもよく覚えてない (^_^;)

  メソッド情報が書ければ prec は

  def prec(klass)
    if klass in 自分が知っている精度クラス達
      適切な処理
    else
      klass.coerce(self, :prec) を使って
      なんとかする
    end
  end

みたいに書くことになるんじゃないかというのが私の
考えです。といっても実質、klass側では精度変換の
処理を induced_from のところに書くか、coerce の
:prec のケースのところに書くかくらいの違いでしか
ないのでしょうが。
---
                        豊福@パパイヤ
                        unbound / papaya.juice.or.jp
                        toyofuku / juice.or.jp