[ruby-list:20764] Re: opttest.rb of optparse-0.6

Toshです。

In message "[ruby-list:20757] Re: opttest.rb of optparse-0.6"
    on 00/02/16, [e-mail] <[e-mail]> writes:
>> OptionParserのサンプルスクリプトopttest.rbですが、0.6になって、
>> OptionParser.newがブロックをinstance_evalでなくyieldするようになった影
>> 響でエラーがでます。
>
>  すいません。opttest.rb 直してませんでした。m(__)m
>
>  変更点についてもっときちんと書いておくべきでした。0.6 と一緒に
>0.5.2 も出してますが、これは instance_eval 以外は同じです。
>0.5.2 メインの方が良かったでしょうか。
># もし二本立にするなら 0.6 と 0.7 とかの方が良かった?

今後ともふたつのバージョンが両立するってことでしょうか？
0.6.0a と0.6.0bってのはどうでしょう？
でも、ふたつバージョンがあると混乱するかも。

>> そもそもinstance_evalしないようになったのはなぜでしょうか？
>> これだとOptionParser.newでブロックとる意味はほとんどなくなる
>> (生成されたインスタンスにブロックからアクセスする手段が無い(?)から)
>> と思うのですが。
>
>  もともとブロックを使う必然性というのはあまり無いんです。
>instance_eval を使う場合、まず危険であるという以外にも、ブロック
>外のインスタンス変数にアクセスできないというデメリットがある一方、
>on とかが直接使えるので書き方がちょっと簡単になるというのと、ブロッ
>クで範囲が分かりやすいというだけで。現に、
>
>opts = OptionParser.new {
>  on("-h", "--help") {puts opts; exit}
>}
>
>と書いても
>
>opts = OptionPareser.new
>opts.on("-h", "--help") {puts opts; exit}
>
>と書いても動作は同じですから(逆にこれが同じでないと、後からオプショ
>ンを追加するということは不可能になってしまう)。
>
>  こう書いた方がよいのかな、と思ってできたのが 0.6。
>
>OptionPareser.new {|opts|
>  opts.on("-h", "--help") {puts opts; exit}
>}

あ、0.6のOptionParser.newはブロック引数がつくのですね。
うう〜む。そうなるとカプセル化やローカル変数のスコープの点で
instance_evalよりはyieldの方がよいかもしれません。納得しました。

ブロックを使う必然性。
ブロックを使うと初期化の作業を一箇所にまとめられるのがOO的に
(あるいはRuby的に)きれいかと思いました。

># 最近 cascade 肯定派に転んだようで、どうやらホントはこんな風に書
># きたいらしい(笑)
># 
># ARGV.options.{
>#   your.banner = "usage: #{$0}\n"
>#   on("-h", "--help") {puts yourself; exit}
># }
># class Foo
>#   def initialize
>#     @foo = false
>#     @bar = false
>#     ARGV.options.{
>#       on("-f", "--foo") {|@foo|}
>#       on("-b", "--bar") {|@bar|}
>#     }
>#   end
># end

カスケーディングはそれほど必要を感じてないですが、
obj. { ... }
よりか
obj do! ... end
とかのほうが個人的には好みかも。
# あまり記号二つつなげたくないらしい。

---
Tosh
Toshiro Kuwabara