From: keiju@... (=?ISO-2022-JP?B?GyRCQFBETTc9PHkbKEI=?= )
Date: 1998-03-20T12:16:23+09:00
Subject: [ruby-dev:1870] Re: [Req] __READLINE__, __FILE__

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

In [ruby-dev :01867 ] the message: "[ruby-dev:1867] Re: [Req] __
READLINE__, __FILE__ ", on Mar/20 10:27(JST) Yukihiro Matsumoto
writes:

>まつもと ゆきひろです

>|  __LINE__
>|  __FILE__
>|
>|が変更できると非常に嬉しいのですが...
>だめ．これらは定数(正確には疑似変数)です．

だめ... いつになく厳しいお言葉...
# いつもなら話しだけでも聞いてくれるのに(;_;

いつでも代入できるようにしろといっているわけではなくて, eval strすると,
__LINE__, __FILE__が意味がなくなっているなくなっているのは事実わけです
から, 逆に設定できる方がより意味のある(ユーザに分かりやすい)数値になる
と思いますが, いかがでしょう?

  eval(str, binding, file_name, line_no)

みたいな感じでオプショナル引数を増やすことになるとおもいます.

または, eval中の__FILE__/__LINE__の表示を自動的に変えてもらっても良い
です. でも, evalに文字リテラルを渡すと正しいから... eval strのように変
数を渡した時, だけ変えるって感じですか...

# でも, 実はmarshalの中では, __FILE__の操作をやっているでしょう?

>|これが使えると, rbcでエラーのあった行を正確に出力できるからです.
>
>エラーの行の情報は結局$@から取り出しているんだから，こっちを
>修正するってのが筋だと思います．またraiseの第3引数に$@と同じ
>フォーマットでtracebackを明示的に指定できます．

それも, 考えられなくもないんですが...

1. 現在のeval strのエラー行表示は不完全で実際にエラーがあった行が良く
   分からない.  
2. なんとなくエラー行のパターンは分かるが, いつもそうなのか?
3. 文字列中から数値を取り出すのも何か... そのフォーマットだっている変
   わらんという保証もないし...
4. 筋といっても... C/C++は(プリプロセッサレベルですけど)変えられるわけ
   だし.... 
5. もし, $@で対応しても,

rbc0> __LINE__
154
rbc0> begin
rbc1* p __LINE__
rbc1> p __LINE__
rbc1> p __LINE__
rbc1> end
155
156
157
nil

   見たいのはそのままだし...

というわけで, もうちょっと考えてもらえませんか...

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