けいじゅ@日本ラショナルソフトウェアです.

In [ruby-dev :4648 ] the message: "[ruby-dev:4648] Re: module
Precision ", on Feb/03 21:48(JST) GOTO Kentaro writes:

>ごとけんです

>>一所懸命検討して下さったのに何なんですが, 
>それはいいんです。一所懸命考えたら採用ってのも変だし(^^;;

(^^;;;

>これは気持は分かるのですが、mixin でクラスメソッドを
>定義することはできるのですか??

あ. できませんね. 失礼しました(__;;;

# method_missingを用いればできないことはないんでしょうけども...

>問題は induced_from と prec の実装で、どこまで他のクラスの
>メソッドを使ってよいかという基準が曖昧だということです。
>この点をはっきりさせるために、
>
>  * prec (-> induced_from (-> terminal_prec))
>  * induced_from の実装で prec を使うのは禁止
>  * terminal_prec の実装で prec や induced_from を
>    使うのは禁止。
>
>という導出のモデルを明確にした方がよいと考えました。

なるほど. 提案の意味を良く理解できていませんでした.

>>現在の僕の考えは、新しく精度をもった数値クラスを実装する人は
>>クラスメソッド induced_from と terminal_prec を用意し、
>>Precition をインクルードするというモノです。
>>これに対する何らかのコメントをどなたかお持ちですか??
>
>というわけです。
>やっぱり冗長に思われますか?? 

冗長というか... 少し分かりずらいモデルになっていると思います.

原案では.

* precの再定義
* induced_fromの定義

となっています. で, precの処理の流れを考えると

aNewNum.prec(A_OldNum)

1. 自分の知っているクラスの変換はここで行なう.
2. 分からんクラスは, そっちのクラスに頼む(A_OldNum.indeced_from(aNewNum)

って, モデルですよね. 

ところが新案では, 逆になっているというか何というか... precの処理の流れ
をかなえると:

aNewNum.prec(A_OldNum)

1. まず, A_OldNum.indeced_from(aNewNum) を呼ぶ.
2. A_OldNum.indeced_fromで分からなかったら,
   aNewNum.terminal_proc(A_OldNum)を呼ぶ
3. aNewNum.terminal_proc(A_OldNum)でそれなりの変換を行なう

って感じです. 

原案は新規にクラスを作る側でやりたいことをやって, もしできなければ相手
のクラスに頼むというモデルで新規にクラスを定義する側が主体になっていま
すが,

新案では, 相手が変換できなかったものをterminal_procで対応するって感じ
になっています. つまり, 相手側が主になっているので, 新規クラスを実装す
る側としては, ちょっとイメージがわきずらいのではないかなって気がします.

>もちろん induced_from で prec を使わないといっても他の
>メソッドから間接的に prec を使ってしまうとやっぱり困ります。
>が、上の導出モデルを書いておく場所として、prec のマニュアルと
>いうのはよいかなとも思います。さもなくば、昔のままだと、
>
>  * prec の実装で induced_from を使うのは禁止
>
>もしくは
>
>  * induced_from の実装で prec を使うのは禁止
>
>というようなことをどこかに明示しておく必要があると思います。

ちゃんと書いてないといけないとは思いますが, そんなに間違いをおかしやす
いかなあって気がしています. それに, 数値関連クラスって実装する人(特に
精度を持ったクラス)はそんなにいないし, それなりに分かっている人たちだ
と思うので, そんなに気にすることはない, っていっちゃ駄目かしら?

__
................................石塚 圭樹@日本ラショナルソフトェア...
----------------------------------->> e-mail: keiju / rational.com <<---