なかだです。

At Wed, 16 Feb 2000 12:22:50 +0900,
Toshiro Kuwabara <toshirok / yb3.so-net.ne.jp> wrote:
> >  変更点についてもっときちんと書いておくべきでした。0.6 と一緒に
> >0.5.2 も出してますが、これは instance_eval 以外は同じです。
> >0.5.2 メインの方が良かったでしょうか。
> ># もし二本立にするなら 0.6 と 0.7 とかの方が良かった?
> 
> 今後ともふたつのバージョンが両立するってことでしょうか?

  異論があった以上、ひとまず 0.5.2 の流れは残しときます。というか
予想して両方出したわけですが、そのうち統一したいです。

> 0.6.0a と0.6.0bってのはどうでしょう?

  うーん、それはでも RCS が許してくれない(笑)。今のところ3つ目は
リリースのたびに、2つ目はインターフェースが変わったりとき(とかそ
の場の気分とか)で上げるって方針でおおむね来てるんで、0.6.0.x と
0.6.1.x にするよりは 0.6 と 0.7 になるかなって感じで。世間的(?)に
も(Ruby とかと同じく)偶数/奇数バージョンでって説明しやすいですし。

> でも、ふたつバージョンがあると混乱するかも。

  そう、まず私が。(^^;

> >OptionPareser.new {|opts|
> >  opts.on("-h", "--help") {puts opts; exit}
> >}
> 
> あ、0.6のOptionParser.newはブロック引数がつくのですね。
> うう〜む。そうなるとカプセル化やローカル変数のスコープの点で
> instance_evalよりはyieldの方がよいかもしれません。納得しました。

  ちょっとこういう用途には instance_eval は強力すぎて、ってとこで
しょうか。なにより self が変わってしまうのが困ったちゃん。

  も一つ非互換性として OctalInteger のような定数が
OptionParser:: を付けないといけなくなるってのがあるんですが。
Integer::Octal とかも考えたものの、一ライブラリの分際であまり無関
係なクラス、とくに組み込みクラスなどにいらん干渉をするのも憚られ
るので(って ARGV 変えちゃってるじゃん。^^;)。

# その辺の定数の module を作って include してもらうって手もあるか。

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

  たしかに当初そういう考えで new で指定できるようにしたんですが、
後からもオプションを追加できるということに気づいて公式仕様とした
時点で、形骸化したようです。

> カスケーディングはそれほど必要を感じてないですが、

  そう思ってたんですが、こういうのこそカスケーディングが一番ハマ
るように思えて来てます。

> obj. { ... }
> よりか
> obj do! ... end
> とかのほうが個人的には好みかも。
> # あまり記号二つつなげたくないらしい。

  bang method ならぬ bang keyword ですか? どうすればいいのかなぁ。

-- 
そうだ 強気に ちょっと インチキに☆彡
    中田 "Bugるくらいがちょうどいいかも;-)" 伸悦