[ruby-dev:40266] Re: ERB#src (was Re: Re: [Feature #2366] private constant

遠藤です。

2010年1月30日21:39 Masatoshi SEKI <[e-mail]>:
> なぜ現在のRubyの状況ではProcの方がよいのですか？
> 私は1.9.xでそう変更すべきでしょうか？
>
> ERBはeRubyのスクリプトからRubyのスクリプトへの変換を担当します。
> ERB#srcこそが本来やりたかったものです。

作っていると曖昧になりがちですが、「ERB の言語を実行する」が目的で
あり、「ERB の言語に相当する Rubyコードを合成する」はあくまで手段
ではないでしょうか。
この目的を達成するために、手段の詳細を下手にさらけ出すと、将来の
改良やバグ修正で仕様を変更することになるリスクが高いと思ったため
Proc の方がいいといいました。

でも、Proc にすると

> 変換結果をファイルを書く人もいるようですが、Procを作るなり
> 好きに使えばよいと思います。

Proc は Marshal できないからファイルに書き出すというユースケースが
満たせなくなりますね。すみません。


>> 推察するに、「実行可能な Ruby コードの文字列を返す」というのが仕様
>> でしょうか。
>
> いえ、実行可能なRubyコードかどうかは、元の文字列によるので
> わからないと思います。

もうちょっと言うと「ERB 言語として正しい記述が入力されたら、実行
可能な Ruby コードの文字列を返す」ですかね。
「ERB 言語として正しい記述」ってなんだ、ということになりますが。


> あー、でもrubyspecって本当はなにをテストしたいんだろう。
> テストじゃないんでしたね。仕様か。
> 仕様っていうのはいつもテストコードに書けるんですかねえ。

書けないですね。極端な例では、String#dump は「必ず停止する Ruby
コードを出力する」という仕様があると思われますが、停止性判定は
決定不能なので判定できないです。


> というかテストコードにあるケースだけをパスするのが仕様なのかなあ。

rubyspec は正確には、「Ruby 処理系が満たすべき仕様」と「仕様に
沿っていることをざっとチェックする conformance test」の組です。
rubyspec は実際には

describe "Array#zip" do
  it "returns an array of arrays containing corresponding elements of
each array" do
    [1, 2, 3, 4].zip(["a", "b", "c", "d", "e"]).should ==
      [[1, "a"], [2, "b"], [3, "c"], [4, "d"]]
  end
end

みたいに書かれています。この中で「仕様」なのは、

Array#zip returns an array of arrays containing corresponding elements
of each array

の自然言語の部分です。ブロック中にあるのが「conformance test」
です。


> はたして、本当にあのときとバージョンとこのときのバージョンが
> 返す文字列が違うにも関わらず、そういうことを記述しなくても
> よいのでしょうか。

なんかわかってきました。それは多分設計仕様とか詳細仕様とか言われる
ものですね。

rubyspec は「MRI と添付ライブラリの詳細仕様」ではなく、「Ruby 言語と
標準ライブラリの外部仕様」を書くことを目的としています。
「これを満たしていれば Ruby を名乗っていいよ」という基準なので、
実装方法など細かいことを規定しすぎると、ある OS では Ruby を名乗る
プログラムを作れないとか、最適化したら Ruby を名乗れなくなったとか、
問題が起こりますので、ある程度自由度のある仕様にする必要があります。

# といっても、以上は私の理解なので、間違っているかもしれません。
# rubyspec は「Ruby のバージョン間の違いを網羅する」というサブの
# 目的も掲げていた気がするので、そっちの意味では書いた方がいいのかも。


> その文字列の変化によって、おかしなユーザのコードが奇妙な
> 挙動を示すこともあると思いますが、そういうのを調べる手がかり
> なりそうに思うんだけどなあ。
>
> そういうセンサーではないなら、ま、いっか。

それはそれで価値があるものですが、rubyspec ではなく test/ 以下に置く
といいと思います。


> 時間と元気があるときに、evalするようなテストケースを提案してみます。
> 英語で意図を説明するのは私には無理なので、コード送ります。たぶん。
>
> 多くの方にご迷惑おかけして申し訳ありませんでした。

いえ、全く迷惑ではないです。
ERB の設計意図がいろいろわかったので参考になりました。

-- 
Yusuke ENDOH <[e-mail]>