豊福@パパイヤです。

けいじゅさん

> 現行のcoerceの理想は
>   Ba Bb
>   Aa Ab
> という計算表がある時に C (= c) というクラスを加えたとき
>   Ca Cb Cc
>   Ba Bb Cc = c.coerce(B)c
>   Aa Ab Cc = c.coerce(A)c
> これで済むようにしているんですよね. 

    Ba Bb Bc = c.coerce(B)c
    Aa Ab Ac = c.coerce(A)c
ですね。
  c.coerce の中も簡単にすめば見た目も中もきれいで
話はここで終わりなんですが、そうでないケースがある
ので話は続きます。:-)

> 先ほどの例でもあるようにcoerceが使えるなら使ったほうがコーディング料は減
> ると思うんですよね. それに演算を行なうこととcoerce(型変換)を行なうことは,
> 本質的に違うので分離できるならしたほうがよいのではと思います.

  同感です。今回の「左側からの演算」の提案も「演算を行なう
こと」と「coerce(型変換)」を切り離すのが目的です。

> ああ. Matrixの話はしないで(^^;;; そうしないと実装できなかったのですもの.

  いやいや、Matrix に続いて Ideal とか左側から(も)
作用されるものを作る人がでてくるでしょうから今のうち
に解決しときましょう。
  ところで前に聞いたかもしれませんが Smalltalk では
Matrix はどう書いてあるんですか。

> 1. 同じクラス同士の演算だったら計算する
> 2. 違っていたら, 自分のcoerceを用いて計算する
> 3. 自分のcoerceが知らなかったら, +!を呼び出す
> 4. other#+!があればそれを実行(option)
> 5. Numeric#+!で, 相手にcoerceしてもらい再演算.
> 
> この案だと, 基本的には演算に関しては自分同士しか考えなくてよいので, 非常
> に管理が楽になるかなと...

  ちょっと気になる点が。

 例えば行列の *演算では「行列 * 行列」だけでなく
「行列 * ベクトル」、「行列 * 数」も同列で定義されていた
方が自然に感じます。
  行列.coerce(ベクトル) が上の方法ではうまくいかないかも。
---
                        豊福@パパイヤ
                        unbound / papaya.juice.or.jp
                        toyofuku / juice.or.jp