ruby-list

けいじゅ＠SHLジャパンです. 

また, 段々メイルが長くなってきてしまいました(^^;; 

In [ruby-list :00712 ] the message: "[ruby-list:712] Re: ? for
Object#extend ", on Oct/02 16:46(JST) matz@caelum.co.jp (Yukihiro
Matsumoto) writes:

>|で, この問題に関わらず, extend/includeした時に初期化を行ないたい時があ
>|ると思うので, extend/includeした時に実行される関数が定義できるようになっ
>|ているとよいと思いませんか?
>あると便利なような，ここまでextendを活用するのはやりすぎのよ
>うな…．悩ましい．

ダイナミックリンクでも初期化関数が呼べるわけですから, いいんじゃないで
すか? 
# 例えが変かな(^^;;

>ビルトインクラスのインスタンスは通常のオブジェクトと違う構造
>を持っているのですが，そこにインスタンス変数を格納するための
>スロットが無いんです．ですから，たとえばSortableの例ではイン
>スタンス変数にアクセスしようとした時点で例外が発生します．

ああ. なるほど. 以前話しのあったクラスの構造が頭にあってあそこ(モジュー
ル用の特異クラス)にはいるのならインスタンス変数が定義できてもいいよう
に感じていました. オブジェクトの構造はまた別の話しでしたね.

>もちろん昔に戻しても良いのですが1ビルトインオブジェクト当た
>り4バイトサイズが増加します．

ビルトインクラスの使用頻度を考えると避けた方が良い気がしますね.

>|>Sortable::newは新しいモジュール(Sortableをincludeしている)を
>|>つくってそれでaをextendするわけです．
>
>-- ここからevalで実装
> module xxxxx
>   include Sortable
>   @cmp = lambda
> end
>-- ここまでevalで実装
> a.extend xxxxx
> a.sort!
>
>をします．つまりextend毎に新しいモジュールをつくってしまうわ
>けです．インスタンス変数はモジュール側で持つと．

モジュールのクラス変数(モジュール変数?)に入れているわけですね.

>|これだと, 初期化の件は解決していると思いますが, インスタンス変数の件は
>|解決していないですよね?
>というわけで，姑息ながら解決しています．

松本氏の方法だと, ビルトインクラスにはインスタンス変数のスロットがなく
とも実現可能になっていると言うわけですね.

>これはやり過ぎならば(今思い付いた別アイディア)，

うーん. 確かに, あまりエレガントではないですねえ...

>  ReverseSortable = Sortable.new{|e1, e2| e2 <=> e1}
>  ReverseSortable.install a
>
>とかかなあ(newは新しいモジュールを作る)．これならインスタン
>ス変数に関して仕様変更の必要は無いなあ．

これは, Structと同じようなアイディアですね. installではaにextendしてい
ると言うことですね.

># ここまで書いて来てSortableというよりもSortedのような気がし
># て来たなあ．

確かに, ここまで来るとインスタンスの性質ではないですね.

>しかし，個々のインスタンス毎に性質を変えるっていうのことその
>ものがやりすぎのような気もするなあ．もしかするとこういう場合
>はwrapperを使うのかもしれませんね．

インスタンスにextendする方法で問題になるのは, そのインスタンスでは[]=
が使えなくなるか意味が変わってしまうというのがあります. だから, extend
することによって, 元のクラスで定義されたメソッドが動作しなくなる可能性
があるんですね(^^;;;

そう言うことを考えると, wrapperの方が良いかも知れません.

>  a = [1,5,3]
>  a = SortedWrapper.new(a){|e1, e2| e2 <=> e1}
>  a -> [5,3,1]
>
>class SortedWrapper
>  def initialize(orig)
>     @cmp = lambda if defined? yield

ここの文の意味が良く分かりません. 

>     @orig = orig
>     sort @orig
>  end
>  def method_missing(id, *args)
>     @orig.send id, *args
>  end
>   :
>end

この方法だと, extendする必要はなくなりますね. 

SortedWrapperは長いのでSortorと言うのはどうですか? この方法でためしに
作ってみますね. 

>まあ，ここまで議論して来てビルトインクラスのextendと特異メソッ
>ドの追加を禁止する必要性は無いと思うようになりましたので，こ
>の件に関しては次回リリースで対応しましょう．

でも, インスタンス変数の件があるので、どうなんでしょうね... extendする
モジュール側に制約がつくわけですね. まあ, そのぐらいの制約はあっても良
いかなあ...

ところで, fixnumにもextendできるようになるのですか? これは何となく無理
そうな気が...

>実際には[key,value]を要素にするという意味ですね．やりたいこ
>とは分かりました．でも，2分木とかトライを実装する時に[],[]=
>だけを期待するインタフェースじゃ効率が悪そうな気が…(実際は
>sizeも必要でしょうね)．

おお. そうなんですよ. sizeも必要です. 

ところで, いまのrubyのモジュールはEnumeratable(eachを前提とする)はあり
ますが, Arrayable(Indexiable?)つまり, [], []=, sizeを前提とするモジュー
ルがないですよね. このモジュールがあれば, Enumeratableにある幾つかのメ
ソッドが最適化されると思いますし, 新たに, sort!, join,...などArrayで定
義されていた幾つかのメソッドが定義可能になります. Arrayに定義されてい
てArrayableで実装不可能なメソッドは, 自分自身へ追加/削除する関数ぐらい
ですかね.

こういうモジュールはどう思います? 今はrubyでこのモジュールをincludeで
きそうなクラスは, Array, Stringぐらいですけど... あと, read onlyですが
Dirもできるかな. あと, 例のSortorもこれがあるとだいぶ楽に使いやすいモ
ジュールが実装できそうです.

無理すればIOもインクルード可能かなと思いますが, IOのばあいはeachが行単
位で[]がchar単位になるので難しいかな...  それよか, rubyでメモリマップ
ドファイルを取り扱えるクラスを用意すればいいんですね. やはり, Thread対
応の次はこれでしょう(^^;;;

__
.....................................石塚 圭樹＠事開事.三井造船(株)...
------------->アドレス変わりました!! e-mail: keiju@csg.mes.co.jp <----

Thread

Prev Next

In This Thread

Prev Next