From: keiju@... (=?ISO-2022-JP?B?GyRCQFBETTc9PHkbKEI=?= )
Date: 1997-12-18T16:20:31+09:00
Subject: [ruby-dev:1144] Re: Object#bind

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

In [ruby-dev :01136 ] the message: "[ruby-dev:1136] Re: Object#bind ",
on Dec/18 14:35(JST) Yukihiro Matsumoto writes:

>まつもと ゆきひろです

>|  Object#bound_method(method_name)
>|
>|でも, これだとレシーバが固定になってしまいますね.
>
>そうです．レシーバに束縛されているんでBoundMethodなんですね．
>石塚さんはモジュールに束縛されていると思ってたんですね．

というかですね. レシーバには束縛されているんですが, 任意のモジュールの
メソッドが束縛できたんです. 

>|  Module#bodoud_method(method_name)
>|
>|って感じのBoundMethodもありますね. この場合はそのModuleに登録されたて
>|いるっていう意味で束縛されています. この場合は, そのModuleの子孫クラス
>|のインスタンスから呼びだし可能で, 次のように使えます.
>|
>|  a_obj.send(bound_method, arg,...)
>|
>|後者の方が, 色々と応用例がありますね. 
>
>これは私の話していたUnboundMethodに近いです．モジュールに束
>縛されているということは上の例では a_obj は module に対して
>kind_of?が成立することを仮定しています？

仮定しています. これなら問題ないかなと思うんですが? 

>とはいえ，もともとの前田さんのBoundMethodの実装が今私の話し
>ているようなBoundMethodでしたからねえ．

ですね. 

>|  Module#bound(method_name, bound_method)
>|
>|これは, bound_methodの束縛しているクラスの子孫クラスにmethod_nameとし
>|て登録するメソッドです. そうすると,
>|
>|  foo = Foo.bound_method(:foo)
>|  Foo.remove_method(:foo)
>|  Foo.bount_method(:foo_org, foo)
>|  Foo.eval_module "def foo; ... foo_org ... ; end"
>|
>|なんてこともできるようになります. 
>|
>|いかがでしょう?
>
>クラスツリーを越えられないのではaliasと変わらない気がします
>が…，どうなんでしょ？

あれは, 効率が云々という話しがあったのでそれよりはいいかも... でも,
それだとsuperの問題は解決しませんね. superの問題を解決するには, alias
の様な機構が必要になるんですよね?

そうすると, MLFの機能として 

  Module#alias(alias_name, method_name)

を用意してもらった方が良いかも... 今はいちいちevalが必要ですし, alias
名に変数が使えないんで面倒なんです.

ここまでの私の結論としては, 

* レシーバは不定の方が嬉しい(BoundMethodの後者の案)
* BoundMethodは, 新たにboundできなくてもよい.
* 代わりにModule#aliasを用意して欲しい

って感じですかね.

>|うーん. 確かにsuperの問題は微妙ですね... 実際にメソッドが定義されてい
>|たクラスからたどっていけば良いような気もしますが, そうすれば良いとも限
>|らないですからねえ...
>
>問題なのはmix-inの関係でrubyは実装上は多重継承になっているの
>でsuperで呼ばれるメソッドが静的には決して決まらないことです．
>で，現在はレシーバのクラス階層から動的に探しているのですが，
>UnboundMethodによってメソッドが要求するクラス階層とレシーバ
>のクラス階層が異なると破綻しそうです．すくなくとも現在の実装
>では対応できません．

そうですねえ. 以外と難しいんですね... CLOSとかはどうやって解決している
んだろう?

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