[ruby-dev:39305] Re: [Feature #2080] Proc#to_source, Method#to_source

　ささだです。

Yuki Sonoda wrote::
> 担当者: Koichi Sasada, カテゴリ: core, Target version: 1.9.2
> 
> [ruby-core:24673]に見るように、Proc#to_sourceやMethod#to_sourceがあると、1.8時代にnode.hを利用してしまっていたようなライブラリの問題の多くを解決できます。そこでnodeやiseqに元のソースコードを持たせておいて、必要に応じてiseqから取得することを提案します。
> 
> 一般的にはコードは処理データに比べて十分に小さいので、メモリ所要量の増加は許容範囲ではないでしょうか。

　私も便利だと思うんですが、ちょっと便利すぎだし、仕様の検討も、凄く自由
度のあるわりに議論が十分ではないので 1.9.3 を目指して議論するといいと思
うんですが、どうでしょうか（つまり、2ヶ月で収束するとは思えません）。

　便利そうだから、みんな喜んで使うと思うんですが、喜んで使うと思うので、
やっぱり仕様変更、っていったときギャっという人は多いんではないかと思います。

　例えば、分からない点として、ぱっと次のような点が思いつきました。思いつ
いた順に書いてるので、仕様と実装の話が混じっています。

1. 引数は？
 1.1 オプショナル引数は？
2. C で書いたメソッドは？
3. ISeq#to_source じゃないの？
 3.1 ISeq は CRuby 固有じゃない？
4. 全てのメソッドの文字列表現をとっておくのは意外と大きいのではないか？
   たとえば、Rails だと数十MBものメモリをそれで消費しないか？
 4.1 圧縮する？
 4.2 ファイル名、ポジションだけ保存して、ファイルから読み込む？
  4.2.1 ファイルの変更があったらどうする？
  4.2.2 eval だったらどうする？
  4.2.3 実は、eval 部分だけ保存しておいて、あとはファイルからで
        十分だったりしない？　ファイルの日付も一緒に保存しておいて、
        日付が違ったらエラー or nil とか。うーん、使いづらいかな。
 4.3 必要な場合は、trace と同様に何か require したら、その後作成した
      iseq はソースを保存するようにするとか？　でも、Rails はまず使い
      そうだから、メモリ消費量に関する解決にはならないな。
 4.4 各文字列を VALUE にするとGC pressure が増えて嫌だなあ
     -> 別途管理？
 4.5 temp file 作っちゃう？　Ruby 起動するたびに数十MBのディスクを消費、
     嫌だなぁ。
5. どこまで返す？
 5.1 メソッド内メソッド定義は？
 5.2 というか、Proc 内のクラス定義、メソッド定義、ネストした Proc は？
6. コンパイラ
 6.1 事前コンパイラを作ったり作らなかったりしているんですが、
     その場合どうなるのかなぁ。
7. CRuby 以外はどうなんだろ。

-- 
// SASADA Koichi at atdot dot net