[ruby-list:16793] RD and internationalization

青山です。

On Tue, 14 Sep 1999 16:17:43 +0900,
Minero Aoki <[e-mail]> wrote:

> プログラムの文字列の場合は、スキャンを通すのは簡単です。即値の
> 埋め込みにこだわる必要はありませんから、文字列を加工した形で
> 保持し、プログラム中で明示的/暗黙的に元の形を復元することが
> できます。

RD の話の流れとしては同意しますが、実際にそのようなコードを書く場合に
はなかなか面倒だと思われます。RD を base64 で埋め込むのがあまり評判が
良くなかったように、プログラム中の文字列であっても、デコードしなければ
読めないデータが含まれるのは不便でしょう。

また、書く方にしても、一々何かで書いて、エンコードして、それを埋め込む
となると、書くのもデバッグも大変です。

この事から、出来ればプログラム中の文字列についても RD と同じように気軽
に扱える方法が提供されると嬉しいです。(そういう意味での同様に検討した
いという言葉のつもりでした)

> 一方で、ソース埋め込みのRDはASCIIに限ることにすれば、RDのスキャンには
> 問題はなくなります。使われる可能性のあるすべてのキャラクタセットに
> 対応することは不可能ですから、この妥協は現状ではやむを得ないと思います。

私もそのように思っていたのですが、=begin, =end 内は ASCII 以外も入れて
大丈夫そうな気がして来ました。=end が来るまではどのようなデータでも無
視されるようですから、例えユニコードが入ったとしても、偶然にも行頭で
=end にマッチするような状況の発生する確立はほぼ無視して良いレベルにな
りそうですから。

> ようするに、プログラム中の文字列とRDの問題は似てはいるし、根源は
> 同じところにあると思いますが、対策も方針も環境も違う。
> 結論としては、このふたつの問題はきっちり分割するべきだと思います。

一方は =begin, =end 内のみ、一方は文字列リテラルすべてという事で、対策
が異なるであろう事は確かですから、分離して検討する事には賛成します。ま
た、現状ではドキュメントの整備の方が先に必要であると思われるので、この
まま RD について検討していくのが良いでしょう。

ただ、その後ででも、プログラム中の文字列リテラルについてもぜひ検討して
いきたいと思います。


-- 
青山 和光 Wakou Aoyama <[e-mail]>